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
