From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Baines Subject: Re: What exactly guix pull does and why is there a seperate profile at ~/.config/guix/current ? Date: Tue, 14 May 2019 08:30:44 +0100 Message-ID: <87tvdxmr17.fsf@cbaines.net> References: <20190513190201.2koyiyoa7zzdcqy6@NUC.doronbehar.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:38808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQRth-0003Cs-G8 for help-guix@gnu.org; Tue, 14 May 2019 03:30:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hQRtf-0005Se-U7 for help-guix@gnu.org; Tue, 14 May 2019 03:30:49 -0400 Received: from mira.cbaines.net ([212.71.252.8]:33852) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQRtf-0005RP-Je for help-guix@gnu.org; Tue, 14 May 2019 03:30:47 -0400 Received: from localhost (cpc102582-walt20-2-0-cust14.13-2.cable.virginm.net [86.27.34.15]) by mira.cbaines.net (Postfix) with ESMTPSA id 8854116F93 for ; Tue, 14 May 2019 08:30:46 +0100 (BST) Received: from capella (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id bdfd7f67 for ; Tue, 14 May 2019 07:30:46 +0000 (UTC) In-reply-to: <20190513190201.2koyiyoa7zzdcqy6@NUC.doronbehar.com> 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 --=-=-= Content-Type: text/plain Doron Behar 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEPonu50WOcg2XVOCyXiijOwuE9XcFAlzabqRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcACgkQXiijOwuE 9Xfsmw/+NV1wULuUGuDyQ7RPH0PVmFT3FUgI2flbbkDFnXpUNvVhsZR7xS+9pBnJ ziVPSI9ZJ5XG8aemdJo2X/RerprKTKXf/96TBHPVEldt7FJn6FIfaGGQJxbUn2dC 6+g2D77JCnvfH0TIlWtx2AQ/0T80gSxj5AwZlBxOSp9Suw2aYe5VehQbL0mXvG7f /Qv/snhfIDHRvoo7ok2/p7oZM92taW0bJQoIVvMLqOWRZKv5pPJ5goiPq/T8afdh 0UkFvLKuIlbQl0w2qOgw0mB3Nk6MEtbcK0gM6+RtqzBGKzYkTxLW4A+CLRWHO9QB M/ykkItEP+aW3pn8UJ3Kf5Z6R1QpoeVmNvxQfupdp6VWsaeQFFM5yJJ//FqBC/3j tQ1vnV6EB9vmzmZBcvMu/zY3LLwAPfUKdGikKNe5NOhe4nFSIoJpJjEEMp2q9xkv 4tQ104Ahnp3QZgMHph/cumlIkC6ygqxgWFOUSpo6PLymXxecw+LZuvwHecIBugtz JVL27j9WI3YgkMf3EBZMwbZppCjOB4LJte2aj6BIQUUjtwU1vSGBOaj9Jwx47gLN sS+9ZHwxAsOfuqLVxoEBfGg7gsIOhp8mBzst18MAkNz1MAcHu322pBq42s23rZSs mN83UUnfjfiZdiyzH3z2fNYlBLkKbhAIobPA5ljx8t2SXfeRo2U= =+vy7 -----END PGP SIGNATURE----- --=-=-=--