From mboxrd@z Thu Jan 1 00:00:00 1970 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 Message-ID: <20190514105033.bnh6haadn3lrkgnc@NUC.doronbehar.com> References: <20190513190201.2koyiyoa7zzdcqy6@NUC.doronbehar.com> <87tvdxmr17.fsf@cbaines.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Received: from eggs.gnu.org ([209.51.188.92]:38903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQV1Q-0004mE-9D for help-guix@gnu.org; Tue, 14 May 2019 06:51:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hQV1O-00081S-Nm for help-guix@gnu.org; Tue, 14 May 2019 06:51:00 -0400 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]:36198) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hQV1O-00080D-FD for help-guix@gnu.org; Tue, 14 May 2019 06:50:58 -0400 Received: by mail-wm1-x344.google.com with SMTP id j187so2326688wmj.1 for ; Tue, 14 May 2019 03:50:58 -0700 (PDT) Received: from localhost (bzq-79-180-236-30.red.bezeqint.net. [79.180.236.30]) by smtp.gmail.com with ESMTPSA id n1sm2139889wmc.19.2019.05.14.03.50.55 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 14 May 2019 03:50:56 -0700 (PDT) Content-Disposition: inline In-Reply-To: <87tvdxmr17.fsf@cbaines.net> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: help-guix@gnu.org 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.