Hi Ludo, Ludovic Courtès <l...@gnu.org> writes:
> I’m not sure I understand the use case. Two different but “common” (?) > use cases come to mind. > > First one is when you want to share the exact same environment within a > team of developers, say. In that case, you have a ‘channels.scm’ that > pins commits. The first ‘guix time-machine’ is expensive but subsequent > invocations are instantaneous (cached). Occasionally, the team updates > ‘channels.scm’ to point to a more recent commit of Guix and other > channels. > > Second one is CI-style: you want to build a package against the latest > commit of each relevant channel, all the time. In that case, you pay > the price on every ‘guix time-machine’ invocation. > > You seem to be looking for something kinda “in between”, is that > right? Yes, that "in-between" use case is what I'm going for. Hard-pinning solves, for example, the "random 5 minute time-machine when invoking Geiser" problem (minus the first use), but introduces others that aren't universally desirable in a short-lived development environment. In other words, it's overkill sometimes. :) In a development environment, I want to achieve two things that are diametrically opposed: 1. Responsiveness/Speed of entry 1. Should be obvious why this is good ;) 2. Continual updates of channels unless explicitly pinned 1. Detect breakages faster without needing a dedicated Cuirass CI server. 2. Less maintainence burden to regularly update pinned commits, particularly as a channel dependency tree grows. I feel that soft-pinning strikes a balance between those two goals that is useful when dependencies on a frequently updated channel are unlikely to break between commits. Elaborating on 2.2, consider a dependency chain that looks like --8<---------------cut here---------------start------------->8--- _______ / \ / v Guix-->A-->B --8<---------------cut here---------------end--------------->8--- If B hard-pins Guix to "foo" and A is updated to Guix "bar", B needs to update their hard-pinned Guix commit in channels.scm to >= "bar" to have a functional development environment again. Alternatively, B could hard-pin A, but if A is a channel the developers of B control they probably want to always use the latest version. Now you're in a catch-22 situation of "Do we hard-pin Guix in B and manually update it every time A's requirements change, or do we not pin Guix at all and deal with regular 5 minute pauses during development?" As channels become more popular and dependency trees grow, this'll become even more annoying. If B is only importing a couple Guix modules that are unlikely to incompatibly change, it's basically wasted effort. This is outside the scope of this topic, but I think it could be interesting if the dependency channels in .guix-channel could specify minimum commits as well. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.