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

[Ludovic Courtès]

Hi Richard,

Richard Sent <richard@freakingpenguin.com> skribis:

> If I want to use time-machine as part of entering a development
> environment for some channel collection and a new guix commit is pushed,
> then the next time I invoke that same time-machine command there will be
> a large delay as Guix fetches, authenticates, computes, and builds an
> entirely new derivation. With your proposal, I'd only avoid that problem
> if I coincidentally happened to run guix pull in-between.
>
> I don't believe hard-pinning the guix channel is an appropriate solution
> in this case since it has several drawbacks as discussed in [1].

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?

Ludo’.