GNU bug report logs - #68912
Guix-home search paths shadow .config/guix/current

Previous Next

To reply to this bug, email your comments to 68912 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christina O'Donnell <cdo <at> mutix.org>
To: bug-guix <at> gnu.org
Subject: Guix-home search paths shadow .config/guix/current
Date: Sat, 3 Feb 2024 13:12:14 +0000

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

Message #8 received at 68912 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> student.tugraz.at>
To: Christina O'Donnell <cdo <at> mutix.org>, 68912 <at> debbugs.gnu.org
Subject: Re: Guix-home search paths shadow .config/guix/current
Date: Thu, 08 Feb 2024 10:07:28 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.