bug#68912: Guix-home search paths shadow .config/guix/current

bug#68912: Guix-home search paths shadow .config/guix/current

[Christina O'Donnell]

Hi,

On my machine the order of search paths are:

$ echo $PATH | tr : '\n'
/home/cdo/.guix-home/profile/bin
/home/cdo/.guix-home/profile/sbin
/run/setuid-programs
/home/cdo/.config/guix/current/bin
/home/cdo/.guix-profile/bin
/run/current-system/profile/bin
/run/current-system/profile/sbin
/gnu/store/gjsxzcc0gqpz4lpbsrbidlnn5ij1lfm1-gzip-1.12/bin
/gnu/store/z81jl0pb4ppkci4im6n856dkhi2ki2d3-coreutils-9.1/bin

This leads to unexpected results if you have Guix inside your home 
package list. (Which you might desire if you wanted to use Guix in a 
home container.)

The Guix you interact with stays stuck on the version that you had when 
you first `guix home reconfigured` a configuration with guix as a 
package. Then `guix pull` appears to succeed but `guix describe` is 
still stuck at the original version. And even a `guix home reconfigure` 
doesn't update the version because it's using the `guix` from the 
original `guix home reconfigure`.

The way out of this situation is to use 
`~/.config/guix/current/bin/guix` directly, setting $PATH manually, or 
simply removing `guix` from your home package list. However, the 
situation is preventable and undesirable and there's several possible 
solutions:

  1. Reorder the paths by default, keeping ~/.config/guix in front of 
~/.guix-home
  2. Have `guix home` warn when 'guix' is included as a package
  3. Have `guix pull` warn when Guix is shadowed and unable to be updated

My preference would be at least 1 and 3.

(Incidentally, how did gzip and coreutils get in there? I didn't put it 
there.)

I'm happy to contribute a patch if others agree that it's worth fixing.

Excited to contribute more!
  - Christina

----------------

Supplementary output:

$ guix describe
   guix aeb4943
     repository URL: https://git.savannah.gnu.org/git/guix.git
     branch: master
     commit: aeb494322ca9dec4a4d66a7d063239c8536bd538
$ guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Updating channel 'nonguix' from Git repository at 
'https://gitlab.com/nonguix/nonguix'...
Building from these channels:
   guix      https://git.savannah.gnu.org/git/guix.git    9389070
   nonguix   https://gitlab.com/nonguix/nonguix    fe2fcf1
Computing Guix derivation for 'x86_64-linux'... \
nothing to be done

hint: After setting `PATH', run `hash guix' to make sure your shell 
refers to `/home/cdo/.config/guix/current/bin/guix'.

$ hash guix
$ which guix
/home/cdo/.guix-home/profile/bin/guix
$ guix describe
   guix aeb4943
     repository URL: https://git.savannah.gnu.org/git/guix.git
     branch: master
     commit: aeb494322ca9dec4a4d66a7d063239c8536bd538

bug#68912: Guix-home search paths shadow .config/guix/current

[Liliana Marie Prikler]

Am Samstag, dem 03.02.2024 um 13:12 +0000 schrieb Christina O'Donnell:
> This leads to unexpected results if you have Guix inside your home 
> package list. (Which you might desire if you wanted to use Guix in a 
> home container.)
The wisdom "One does not simply 'guix install guix'" has been passed
around for ages.  Same applies to home configurations, which merely
mimic that aspect.  There are valid reasons for using Guix in temporary
shells (or home containers), but also many pathological uses.

> [T]he situation is preventable and undesirable and there's several
> possible solutions:
> 
>   1. Reorder the paths by default, keeping ~/.config/guix in front of
> ~/.guix-home
As far as I know, this requires changing the order in which files are
sourced, and it's not clearly desirable that ~/.config/guix ought to
shadow ~/.guix-home or ~/.guix-profile.  In particular, whenever you
use `guix shell` or similar, you will shadow that anyway.

>   2. Have `guix home` warn when 'guix' is included as a package
This might be fine, but what about the home container use-case then? 
I'm not sure whether having no guix in containers is preferable over
having a slightly outdated one – at the very least, my personal usage
of GWL through `guix shell' is enough reason to keep guix visible as a
package.

>   3. Have `guix pull` warn when Guix is shadowed and unable to be
> updated
This would (at least in a naive version) print a weird warning on fresh
setups, where the not yet created local ~/.config/guix is not yet on
PATH.  As far as I know, this would be doable, though, if you're smart
enough about it.

> (Incidentally, how did gzip and coreutils get in there? I didn't put
> it there.)
These might have been added by the home container for reason
unbeknownst to me.

> hint: After setting `PATH', run `hash guix' to make sure your shell 
> refers to `/home/cdo/.config/guix/current/bin/guix'.
Hint: this is the warning you're looking for.  It's phrased as a hint,
because people typically only encounter it once during setup.

Cheers