bug#31841: ./pre-inst-env guix system no longer works without ~/.config/guix

[George Clemmer <myglc2@gmail.com>]

Mark H Weaver <mhw@netris.org> writes:

> Hi,
>
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> myglc2@gmail.com skribis:
>>
>>> Based on this thread I am now making guix like this ...
>>>
>>> guix environment guix --ad-hoc guile-sqlite3 --root=build-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, “Building from Git” mentions
>> ‘guix environment guix’, but “Running Guix Before It Is Installed”
>> doesn’t.  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 distinguish 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 environment
>> +with all the dependencies available (@pxref{Building from Git}), and then
>> +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 “--ad-hoc guile-sqlite3” because
>> it has become unnecessary with commit
>> c5a2e1ffcb029f50c4c18352cf378b61c41c625e.
>>
>> Likewise, I did not mention “source build-env/etc/profile” because
>> “Building from Git” suggests using ‘guix environment guix’, 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=build-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. 

2) Add the guix dependencies to the harness's custom profile so 'guix
   environment guix' won't be needed.  

WDYT? - George