Questions and feedback on default checkout and lockfile behavior

[pbuteau]

Hi,

My name is Patrice. I’ve been using kas 4.7 for some time now and overall I think it’s an excellent tool. That said, there are a few behaviors that initially caught me off guard, and I’d like to share them both to confirm my understanding and to suggest possible improvements.

1. kas build performing a checkout by default

One thing that surprised me is that kas build performs a repository checkout by default. Based on the command name, I expected it to strictly perform a build. Conceptually, I would have expected checkout behavior to be opt-in (for example, via something like kas build --checkout).

In my current workflow, I consistently use kas build --skip repos_checkout, which feels more predictable and aligns better with my expectations.

2. Inability to lock the current local state

It also appears to be impossible to generate a lockfile that reflects the currently checked-out local state. Running kas lock seems to validate the kas configuration file against the lockfile it is about to generate and fails if they do not match.

I would have expected kas lock to behave more like a snapshot of the current workspace state—similar to what pip freeze provides—rather than enforcing strict alignment with the configuration file.

3. kas checkout behavior when a lockfile is present

Related to point (2): when a lockfile is present, running kas checkout attempts to validate the kas configuration file against the lockfile and fails if the commits listed in the lockfile are not on the branches specified in the configuration.

My expectation in this case would be that, when a lockfile exists, kas checkout simply checks out the exact revisions defined in the lockfile, without additional validation against the configuration branches.

---

I understand that point (1) may involve broader design considerations and might require more discussion. However, points (2) and (3) seem like reasonable enhancements that could potentially be added without changing existing behavior.

I’m happy to help further if needed, whether through discussion, testing, or contributions.

Thanks for your time and for maintaining kas.

Best regards,
Patrice

[jan-kiszka]

Thanks for bring this up, and sorry for the late reply - the majority of discussions happen on our mailing list (kas-devel@googlegroups.com).

Looping in @fmoessbauer as author of the lock plugin.

[fmoessbauer]

Regarding lockfile behavior: Yes, that's a valid point. However - as you see - kas is build around the idea of a configuration that describes everything. That's also why kas build does the checkout, as it anyways would only build what the configuration specifies. One exception to this rule are dirty repos (repos with uncommitted changes), which are ignored by the checkout logic.

In theory, we could implement "pip freeze" like behavior in the lock plugin, but technically that requires a redesign as we currently perform the checkout upfront. I'll think about it.