Doron Behar <doron.behar@gmail.com> writes:

> I'm using Arch Linux and I'd like to get my hands dirty with Guix as an
> alternative (but better) package manager. Unfortunately, I'm very
> confused as for the role of `guix pull` and `guix package -u` and the
> 'current guix profile' symlinked to ~/.config/guix/current .
>
> 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.

> Usually, the repositories (or more precisely, the package definitions)
> are managed separately from the source code of the package manager
> itself, and very reasonably IMO. Since the source code to retrieve
> packages / reading definitions and building them shouldn't be linked to
> changes such as packages added or updated in the repositories.
>
> 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.

> This wouldn't have been that bad if Guile would have had a compiler
> cache like C and some other languages have (see [ccache][1] and
> [sccache][2]).

While I'm not sure that level of caching would help, or even be possible
due to the isolation of the builds, it is perfectly possible that some
of the derivations computed by guix pull are already built, and don't
need building. Or that a substitute server you've authorised has built
them, and you can just download the data.

> Additionally, I'm not sure I understand the relation between `guix pull`
> and `guix package -u`. Let's say I'm running `guix pull` and some
> packages have been updated / added.  Do I have to use the guix binary in
> ~/.config/guix/current/bin/ in order to install them? Speaking of which,
> what is the purpose of this profile anyway? Why doesn't `guix pull` just
> updates a database of all package definitions and then suggests to run
> `guix package -u` to do all the rest - including updating `guix` it self
> in the default profile **if needed**?

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).

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.

> One more unclear thing for me: If I run `guix pull`, I always get the
> message that I should add ~/.config/guix/current/bin/ to my $PATH so I'd
> use the latest `guix`. Does it mean that with using `guix` from
> ~/.guix-profile/bin I don't really get any updates?

I'm not quite sure, but I'd suggest doing that as otherwise you may be
using an older version of Guix in some respects. The binary installation
docs now say to do this:

  GUIX_PROFILE="`echo ~root`/.config/guix/current" ; \
  source $GUIX_PROFILE/etc/profile

So I'd put that in the relevant initialisation files.

> I hope the design decisions of the way things work now are genius as the
> rest of the ecosystem and that I've failed to see that. Anyway, above
> all, I'm not sure as for what `etc/profile` files to `source` so my $PATH
> and other environmental variables will always be up to date with the
> current state..

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

So, I think it's good to source both the etc/profile files inside both
~/.guix-profile and ~/.config/guix/current, and you should source the
~/.config/guix/current one last, as it prepends the profile directory to
the $PATH.

Hope that helps,

Chris