Improving the speed of guix time-machine for development environments

[Richard Sent <richard@freakingpenguin.com>]

Hi Guix,

To my knowledge what I'm asking for can't currently be done, but if it
can feel free to disregard.

I think channels listed in channels.scm files should optionally support
using whatever channel version is already in the user's profile, if
present. This would significantly speed up entering development
environments composed of Guix channels. Consider the following
situation:

1. Repository A contains some code, an unmerged Guix package, and a
.guix-channel file.

2. Repository B declares an unmerged Guix package that depends on A's
package

3. Repository B doesn't want to duplicate the package definition in A,
so it adds a channel dependency in B's .guix-channel

4. Repository B wants to make it easy to enter a development environment
that includes repository A's channel, so it tracks a channels.scm file
with the following content:

--8<---------------cut here---------------start------------->8---
(append (list (channel
               (name 'B)
               (url (string-append "file://" (getcwd)))))
        %default-channels)
--8<---------------cut here---------------end--------------->8---

Now in order to build B, I need to enter a Guix development environment
that includes A's channel. The only option I know for that is
time-machine, e.g. "guix time-machine -C channels.scm -- build -f
guix.scm".

Unfortunately, *I may be delayed every time I enter the development
environment by several minutes while Guix computes a new derivation due
to an update in %default-channels*.

time-machine will update ALL channels in channels.scm to the master
branch (by default) every time I try to enter a development environment
(e.g. "guix time-machine -C channels.scm -- shell -CDf guix.scm").

I don't think pinning Guix to a specific commit in channels.scm is the
right solution.

1. That increases the maintenance burden (If A updates to use newer Guix
code, now all dependents of A need to be manually updated to use newer
Guix commits).

2. It makes it easy to mask breakages for an extended period.

3. It implies that B doesn't work on newer versions.

4. Any developer working on the repo will pull an unneeded copy of the channel.

I think this is a side effect of time-machine serving dual purposes.
One is providing a reproducible environment for result replication, the
other is providing a development environment for collections of channels.

My proposed solution is to add a (prefer-local?) field to (channel ...).
When set, time-machine would first see if there is a channel with the
same name in the user's profile. If so, it will include that channel in
the time-machine environment instead of fetching it. If not, it behaves
as normal and fetches the channel from url.

As a workaround, it *may* be possible to achieve this via a command like
~guix time-machine -C channels.scm --commit $(guix describe |
<some_crazy_awk_or_grep_chain)~, but I don't feel that this is a valid
solution. From what I understand --commit only works on the 'guix
channel, but I suspect this proposal could prove useful for other major
channels as well. It's also very inelegant :)

As a side effect, `guix pull -C` would support only upgrading certain
channels while "soft-pinning" others. Maybe that's good?

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.