Guix-home search paths shadow .config/guix/current

  • Open
  • quality assurance status badge
Details
2 participants
  • Christina O'Donnell
  • Liliana Marie Prikler
Owner
unassigned
Submitted by
Christina O'Donnell
Severity
normal
C
C
Christina O'Donnell wrote on 3 Feb 14:12 +0100
(address . bug-guix@gnu.org)
7cd7e463-dfe5-4810-dc17-d1175e4696c3@mutix.org
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
    branch: master
    commit: aeb494322ca9dec4a4d66a7d063239c8536bd538
$ guix pull
Updating channel 'guix' from Git repository at
Updating channel 'nonguix' from Git repository at
Building from these channels:
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
    branch: master
    commit: aeb494322ca9dec4a4d66a7d063239c8536bd538
L
L
Liliana Marie Prikler wrote on 8 Feb 10:07 +0100
23c2397e5ac73a5431e16d6fedaf007c5d92f400.camel@student.tugraz.at
Am Samstag, dem 03.02.2024 um 13:12 +0000 schrieb Christina O'Donnell:
Toggle quote (3 lines)
> 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.

Toggle quote (5 lines)
> [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.

Toggle quote (1 lines)
>   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.

Toggle quote (2 lines)
>   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.

Toggle quote (2 lines)
> (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.

Toggle quote (2 lines)
> 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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 68912@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 68912
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch