From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Clemmer Subject: bug#31841: ./pre-inst-env guix system no longer works without ~/.config/guix Date: Sat, 16 Jun 2018 10:31:33 -0400 Message-ID: <87lgbeajlm.fsf@gmail.com> References: <8736xopz0q.fsf@netris.org> <87bmccuwbu.fsf@mdc-berlin.de> <87o9gctgrm.fsf@gnu.org> <87po0snp5g.fsf@netris.org> <87602kro0h.fsf@gnu.org> <874li31wx7.fsf@g1.i-did-not-set--mail-host-address--so-tickle-me> <87sh5nqgtf.fsf@gnu.org> <87po0r3vsn.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54716) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUCFJ-0001lH-Ar for bug-guix@gnu.org; Sat, 16 Jun 2018 10:32:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fUCFG-0002BA-6K for bug-guix@gnu.org; Sat, 16 Jun 2018 10:32:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:43863) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fUCFG-0002Am-1N for bug-guix@gnu.org; Sat, 16 Jun 2018 10:32:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fUCFF-0003OA-LQ for bug-guix@gnu.org; Sat, 16 Jun 2018 10:32:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <87po0r3vsn.fsf@netris.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Mark H Weaver Cc: Ricardo Wurmus , 31841@debbugs.gnu.org Mark H Weaver writes: > Hi, > > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> myglc2@gmail.com skribis: >> >>> Based on this thread I am now making guix like this ... >>> >>> guix environment guix --ad-hoc guile-sqlite3 --root=3Dbuild-env -- make= [MAKECMDGOALS] >>> >>> ... and using it like this ... >>> >>> source build-env/etc/profile >>> ./pre-inst-env guix COMMAND ARGS... >> >> Yeah we can improve the doc. Currently, =E2=80=9CBuilding from Git=E2= =80=9D mentions >> =E2=80=98guix environment guix=E2=80=99, but =E2=80=9CRunning Guix Befor= e It Is Installed=E2=80=9D >> doesn=E2=80=99t. How about this: >> >> diff --git a/doc/contributing.texi b/doc/contributing.texi >> index 205c972ae..3f82f4bc2 100644 >> --- a/doc/contributing.texi >> +++ b/doc/contributing.texi >> @@ -108,7 +108,9 @@ actually installing them. So that you can distingui= sh between your >> ``end-user'' hat and your ``motley'' costume. >> >> To that end, all the command-line tools can be used even if you have not >> -run @code{make install}. To do that, prefix each command with >> +run @code{make install}. To do that, you first need to have an environ= ment >> +with all the dependencies available (@pxref{Building from Git}), and th= en >> +simply prefix each command with >> @command{./pre-inst-env} (the @file{pre-inst-env} script lives in the >> top build tree of Guix), as in@footnote{The @option{-E} flag to >> @command{sudo} guarantees that @code{GUILE_LOAD_PATH} is correctly set >> >> >> Note that I purposely did not mention =E2=80=9C--ad-hoc guile-sqlite3=E2= =80=9D because >> it has become unnecessary with commit >> c5a2e1ffcb029f50c4c18352cf378b61c41c625e. >> >> Likewise, I did not mention =E2=80=9Csource build-env/etc/profile=E2=80= =9D because >> =E2=80=9CBuilding from Git=E2=80=9D suggests using =E2=80=98guix environ= ment guix=E2=80=99, which sets >> up the right environment variables. >> >> WDYT? > > When running Guix exclusively from a git checkout and never running > 'guix pull', something like "source build-env/etc/profile" must now be > run before running 'guix'. > > You seem to be suggesting that "source build-env/etc/profile" could > simply be replaced by "guix environment guix". One problem with this > idea is that it would introduce a circularity. My 'guix' script cannot > very well begin by running 'guix environment guix'. > > There are other problems as well: > > (1) The build environment used to build the git checkout must be > registered as a GC root, or else "guix gc" may render my git > checkout of 'guix' non-functional, with no easy way to recover > (at least not without running 'guix pull'). > > (2) When my git checkout is in a bad state, or is unbuilt, then during > this time I'm unable to easily run "guix environment guix". So, I > always need a way to restore a known good development environment to > rebuild my copy of guix, without using guix itself. My method is to > source the etc/profile from my saved development environment profile. > > I should emphasize that when running Guix this way, if you wish to avoid > running 'guix pull', it's important to always keep at least one > known-good development environment for Guix saved as a GC root. Toward > that end, when I run "guix environment guix" to update my development > environment profile, I make sure to preserve my previous profile as a GC > root until I'm confident that my new profile is working. > > The suggested recipe involving "guix environment guix --root=3Dbuild-env" > command is a nice improvement over my manual management of these GC > roots, but it has one shortcoming: it discards the older profile symlink > and GC root immediately, before it's known whether the new profile works. > > This message should make it clear that when using Guix in this way, it's > easy to get stuck if you're not careful. I suppose that I could always > get unstuck by running 'guix pull', but I prefer to avoid it. > > Regards, > Mark Hi Mark, While I have submitted a few patches, generally I use 'guix pull; make' primarily to manage my GuixSD systems. In the past 2+ years I have had to "resort" to 'guix pull' only a few times, usually to escape the 'guix environment guix' "hole" you describe. Eventually I discovered that if I _never_ did 'guix gc' and did 'guix environment guix' _before_ I did 'git pull', I never fell into the "hole", that is, unless I screwed up and did git pull first ;-) I recently started using gc roots and "custom" profiles and put my guix build into a makefile "harness" to eliminate manual steps. I also switched from the symlink to a script like yours. My script also falls back to the globally-installed Guix if an environmental is set. The harness inflates a custom profile and includes a makefile that calls 'guix environment guix -- make'. I added the gc root to work around the issue raised by this bug. Recently I have been eyeing all the thrashing that goes on when 'guix environment' is run after a "big" pull. Previously I avoided this thrashing and the hole when I remembered to do 'guix environment guix' before 'git pull'. I am contemplating two modifications to the harness: 1) Cache the 'guix environment' gc root at the end of each successful make and a) normally use the cache, or b) fall back to the cache if 'guix environment' fails.=20 2) Add the guix dependencies to the harness's custom profile so 'guix environment guix' won't be needed.=20=20 WDYT? - George