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 18:06:04 +0100 Message-ID: <87sgthm0eb.fsf@cbaines.net> References: <20190513190201.2koyiyoa7zzdcqy6@NUC.doronbehar.com> <87tvdxmr17.fsf@cbaines.net> <20190514105033.bnh6haadn3lrkgnc@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]:50270) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQate-000152-NL for help-guix@gnu.org; Tue, 14 May 2019 13:07:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hQasT-0003Do-EQ for help-guix@gnu.org; Tue, 14 May 2019 13:06:11 -0400 Received: from mira.cbaines.net ([2a01:7e00::f03c:91ff:fe69:8da9]:50858) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQasT-0003Ck-5P for help-guix@gnu.org; Tue, 14 May 2019 13:06:09 -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 8677216FF5 for ; Tue, 14 May 2019 18:06:06 +0100 (BST) Received: from capella (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id cde5dcf4 for ; Tue, 14 May 2019 17:06:06 +0000 (UTC) In-reply-to: <20190514105033.bnh6haadn3lrkgnc@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; charset=utf-8 Content-Transfer-Encoding: quoted-printable Doron Behar writes: >> > 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 C= PU >> > 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. Yeah, I also think there's room for improvement. Just to add more data, you can see the relevant builds for guix pull on ci.guix.gnu.org here [1]. As far as I can see, ae5de93 which you pulled was pushed to master at ~05:47, and the build finished at ~12:59 [3]. Assuming this is correct, that's ~7 hours. I don't think it actually took this long (hopefully), but it probably wasn't started immediately. 1: http://ci.guix.gnu.org/jobset/guix-modular-master 2: http://ci.guix.gnu.org/eval/5333 3: http://ci.guix.gnu.org/build/1321772 As far as I'm aware, this is more of a software issue with the current build farm, that could possibly be addressed with some prioritisation. It probably wouldn't be perfect, but I'd hope if it was just a bit faster, less people would be impacted by guix pull taking a while. >> 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. Maybe I can. Firstly, you probably don't want to have the Guix package in your profile. If you've got it installed, I'd suggest removing it. The package for guix in guix normally referrs to a particular commit, which is updated occasionally. It's in the package version, so you can check this: =E2=86=92 guix package --show=3Dguix name: guix version: 1.0.0-1.326dcbf This package is mainly used by other packages which have a dependency on Guix, for example Cuirass, which is the software behind ci.guix.gnu.org. If I build the guix package, and then run guix describe, I'll get an error: =E2=86=92 /gnu/store/cwlghngrh03igf8cfsp2mf49c2l9fnf5-guix-1.0.0-1.326dcb= f/bin/guix describe guix describe: error: failed to determine origin hint: Perhaps this `guix' command was not obtained with `guix pull'? Its = version string is 1.0.0-1.326dcbf. However, if I run guix describe for the store item generated by guix pull, I get the expected result. =E2=86=92 ~/.config/guix/current/bin/guix describe Generation 72 May 06 2019 11:27:52 (current) guix fc7d632 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: fc7d632829e93bd1c6d2db6f99ce22766ff9c67a --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEPonu50WOcg2XVOCyXiijOwuE9XcFAlza9XxfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcACgkQXiijOwuE 9XcRkw//enkwV+0gi77QSp6pZ7oOltriyaSPqD+CwfYOj3xxI75tneHwC+lescl0 55mXlVdRXacttA4Ya/DqfxMSfF19qm5Csah06SGqF/ctI6QzzIE2vtv4Hcg4fTWr ZExts5brM730kl4k7kl0I95ipxM6npSWIoORlZbzmDYSawyKQmxB5GLDBJHp869A ocQI097NmpGnzdJh948rbcbFHMuRFw82KD8R5L7siTr5pIZAvhEH69vtISPMJBnY 0L7lc4TNMbl2BL6j7CciAtF8CNmWdxIA84FPRFrgSgvsushnUaSHTx47PwQrdpM2 jwhf7s0BoF1hnkwspt2TAiSsMNupmkL+/GsoJdc7HTJFViEa1oGWKF7oZhfH0FIt L/e5wmI3wi5gjBZez9gEevWOn+k5VSsJL9phmNa7igfKGIBxuRQecKSMMjn/dlOw h/s9UTgxFKBP+P5Ysf3FmCY7TRkxg4mBtcI5MtRd/Zjd60ww5YhgCaFQmVFvAJmJ YNDeiZEkq5wygK8zD5dc+AyLgsW2tngar4ja/7YLhq7ObrLlaPaWupY4irEZZOMT CX/WdjNVF3GBjAD/JyIfVjxFw68suare6Wmd0rWuaOqtw22oBwdKCCwT6MzWhOZz RgwiffzqGmKJadl+8LSq5NFv3MZfIw35UPrcNVW1OuI0NcjcYlA= =oRWi -----END PGP SIGNATURE----- --=-=-=--