[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What exactly guix pull does and why is there a seperate profile at ~
From: |
Doron Behar |
Subject: |
Re: What exactly guix pull does and why is there a seperate profile at ~/.config/guix/current ? |
Date: |
Tue, 14 May 2019 13:50:33 +0300 |
User-agent: |
NeoMutt/20180716 |
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.