Re: What exactly guix pull does and why is there a seperate profile at ~/.config/guix/current ?

[Doron Behar]

Thanks for giving your attention Christopher. Most of what you wrote was
very helpful for me to gain an understanding of the ecosystem. I have a
few more doubts though that perhaps could be figured out with help of
someone with better technical background.

On Tue, May 14, 2019 at 08:30:44AM +0100, Christopher Baines wrote:
> > In 'traditional` package managers, there's the concept of a
> > "repository" which seems to correspond to all the scheme code
> > written in gnu/packages/*.scm under the Guix Git repository.
> 
> Yep, Guix doesn't fit the typical repository definition. There's a
> concept of "channels" in Guix (and also Nix I hear) [1].
> 
> 1: https://www.gnu.org/software/guix/manual/en/html_node/Channels.html
> 
> But this relates more to how you access a "repository" of Guix packages.

I'm aware of the idea of channels and I tried to configure that but I've
encountered several issues. I'll post these in a separate thread.

> > According to the documentation, `guix pull` 'updates the distribution
> > along with the Guix tools'. Does it mean that every time something is
> > updated in the actual source code of the remote Guix repository, when I
> > run `guix pull` afterwards my computer builds `guix` and `guix-daemon`
> > from the ground up? Does it actually run `./configure && make && make
> > check` behind the scenes on the source files? If so, that's insanely CPU
> > wasteful and definitely unnecessary.
> 
> The "source form" for Guix package definitions are snippets of Guile
> code. Given this, I think it's not as unreasonable to follow the normal
> processes for building software when getting an updated copy of the
> package definitions...
> 
> I don't have a great understanding of it, but running guix pull doesn't
> just correspond to a single derivation, the task is broken down in to
> multiple parts, some of which might already be done. There's a more
> technical description here [2].
> 
> 2: https://issues.guix.info/issue/27284#43
> 
> Running guix pull isn't quite the same as running ./configure && make &&
> make check. In particular, I don't think it uses ./configure, or runs
> the Guix testsuite.

I've read that 'issue' webpage and it seems the introduced feature
certainly has given a useful improvement but I'm not sure I understand
how relevant it is..

I do understand though that since most of Guix is written in Guile,
packages' definitions are definitely linked to the code that states how
to build them. I guess that means that most it will have to be
recompiled after every update in the repository.

It seems that way from the following stdout of `guix pull` I got today:

https://gist.github.com/doronbehar/fe19099502beecf4fb5c4523d8890862

As you can see, it clearly states multiple times the following:

    building /gnu/store/....drv
    building /gnu/store/....drv
    building /gnu/store/....drv
    ...

And it is also reflected when looking at the CPU usage of this command.
I think there's defiantly room for improving the efficiency of this so
standard and common process..

Note that I'm saying that under the impression that I've setup
substitutes correctly - I've authorized substitutes according to the
documentation and `guix build emacs --dry-run` prints "downloaded" and
not "will be built".

Thinking about it from a Git development work flow perspective, maybe
the Guix project should declare that no other thing then package
additions / version updates should be merged to the master branch and
that all core development should be done on a `develop` branch. This
would hopefully have the effect of having `guix pull` only build
`guix-packages.drv` every time and not everything else as well.

> I'm not quite sure if you _have_ to use the guix binary from
> ~/.config/guix/current/bin, but I think that it's probably a good idea.
> 
> I think .guix-profile and .config/guix/current are separate things, as
> they're quite different. .guix-profile is a profile constructed from
> packages, it has a manifest at .guix-profile/manifest. Whereas
> .config/guix/current I think might be constructed by building all the
> channels you have configured? Because the guix pull process involves
> multiple derivations for different parts, I don't think it's represented
> internally as a package (there is also a package definition for guix,
> but that's not what's being built when doing guix pull).

Thanks for your honesty, I've proven you are correct by comparing the
output of the following commands:

$ ~/.config/guix/current/bin/guix package -A
$ ~/.guix-profile/bin/guix package -A

There were new package and version updates..

> 
> I think there's also advantages for treating them separately, especially
> being able to control the generations separately, so you can roll back
> the .config/guix/current generation without affecting the packages you
> have installed for example.

I'm not sure I agree. After all, `guix pull && guix package -u` also
updates guix in ~/.guix-profile so it means that after that, both of
these `guix` commands in both profiles correspond to the same Guix.. I
hope someone could convince me I'm wrong.

> 
> So, I don't actually have much experience using Guix on "foreign"
> distributions any longer, but on a Guix System, this is included in
> /etc/profile.
> 
>   # Arrange so that ~/.config/guix/current comes first.
>   for profile in "$HOME/.guix-profile" "$HOME/.config/guix/current"
>   do
>     if [ -f "$profile/etc/profile" ]
>     then
>       # Load the user profile's settings.
>       GUIX_PROFILE="$profile" ; \
>       . "$profile/etc/profile"
>     else
>       # At least define this one so that basic things just work
>       # when the user installs their first package.
>       export PATH="$profile/bin:$PATH"
>     fi
>   done
> 

Very helpful indeed, I'll use that in my initialization files.