Richard Sent <rich...@freakingpenguin.com> skribis: > 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 > > _______ > / \ > / v > Guix-->A-->B > > 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.
I see. I wonder if another mechanism I suggested could help: https://lists.gnu.org/archive/html/guix-devel/2024-01/msg00201.html Especially if the channels.json is published by a CI system. Thoughts? Ludo’.
