bug#22629: [PATCH 0/4] 'guix pull' produces a self-contained Guix

[Ricardo Wurmus <rekado@elephly.net>]

> Here is the “new” ‘guix pull’ that we discussed notably in this thread:
>
>   https://bugs.gnu.org/22629
>
> The major difference is that instead of just building a bunch of modules
> and putting them under ~/.config/guix/latest, it now produces a
> standalone package (with bin/guix, share/info/guix.info, etc.) and puts
> it in a profile under ~/.config/guix/current.  […]

This is beautiful!  Thank you so much for taking the time to implement
this.

>
>      The result of running ‘guix pull’ is a “profile” available under
>   ‘~/.config/guix/current’ containing the latest Guix.  Thus, make sure to
>   add it to the beginning of your search path so that you use the latest
>   version, and similarly for the Info manual (*note Documentation::):
>
>        export PATH="$HOME/.config/guix/current/bin:$PATH"
>        export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"

As a profile it will have its very own “etc/profile” file.  I suppose
that doesn’t include INFOPATH, though, because it only contains an Info
manual but not an Info reader.  It would be extra nice if we could
simplify this initial setup even more.

>      This ‘~/.config/guix/current’ profile works like any other profile
>   created by ‘guix package’ (*note Invoking guix package::).  That is, you
>   can list generations, roll back to the previous generation—i.e., the
>   previous Guix—and so on:
>
>        $ guix package -p ~/.config/guix/current -l
>        Generation 1	May 25 2018 10:06:41
>          guix	221951a	out	/gnu/store/i4dfk7vw5k112s49jrhl6hwsfnh6wr7l-guix-221951af4
>
>        Generation 2	May 27 2018 19:07:47
>         + guix	2fbae00	out	/gnu/store/44cv9hyvxg34xf5kblf5dz57hc52y4bm-guix-2fbae006f
>         - guix	221951a	out	/gnu/store/i4dfk7vw5k112s49jrhl6hwsfnh6wr7l-guix-221951af4
>
>        Generation 3	May 30 2018 16:11:39	(current)
>         + guix	a076f19	out	/gnu/store/332czkicwwg6lc3x4aqbw5q2mq12s7fj-guix-a076f1990
>         - guix	2fbae00	out	/gnu/store/44cv9hyvxg34xf5kblf5dz57hc52y4bm-guix-2fbae006f
>        $ guix package -p ~/.config/guix/current --roll-back
>        switched from generation 3 to 2

This also means that you could remove the “guix” package and install
“hello” instead.  If a user did that they would lose their variant of
guix and they’d fall back to whichever version is installed on the
system (if any).  They could still roll back manually by changing the
symlink.

They could also think that installing the “guix” package into that
profile would be a good idea — but then they would end up with a
slightly older version of Guix.  (This is already possible, of course,
but if we have a separate profile that’s intended just for Guix but with
generic properties, this could become confusing.)

I’m just thinking out loud about how users could get into trouble :)

> There are two requirements it fulfills in terms of compatibility:
>
>   1. The modified ‘build-aux/build-self.scm’ still does the right thing
>      when evaluated by an “old” Guix—that is, it produces a bunch of
>      modules for use in ~/.config/guix/latest as before.

Excellent!  Thanks for thinking about this case.

>   2. The modified ‘guix pull’ produces ~/.config/guix/current even when
>      invoked on a commit of a past Guix.  That is, it automatically
>      produces a ‘guix’ command using the modules returned by the old
>      ‘build-self.scm’.
>
> There are various improvements we can make from there.  For example,
> using “manifest entry properties” as proposed in
> <https://bugs.gnu.org/31442>, we can attach meta-data (commit ID, repo
> URL, etc.) in each manifest entry that ‘guix pull’ populates; then we
> can arrange for ‘guix pull --list-generations’ (say) to display that
> information.
>
> We could add ‘guix pull’ options for convenient: ‘--roll-back’,
> ‘--profile’, etc.
>
> Going forward, additional “channels” could be presented as entries in
> the ~/.config/guix/current manifest.
>
> Caveats:
>
>   1. The ~/.config/guix/current profile really lives there.  That is,
>      unlike ~/.guix-profile, it’s not in /var/guix/profiles/per-user.
>      That could be an issue for cluster setups where home directories
>      are not scanned by the Guix GC.  Cluster folks, please tell me!

Is it impossible to store it in localstatedir?

In practice, cluster installations don’t really run “guix gc” all that
ofter (if ever), so it may not be a problem.

>   3. C++ code is not built.  I wonder which will come first: getting rid
>      of the C++ code, or building it?  :-)

I’d say that this is a feature ;)

--
Ricardo