Re: Improving the speed of guix time-machine for development environments

[Richard Sent]

Hi Ludo,

Ludovic Courtès <ludo@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.