unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Liliana Marie Prikler <liliana.prikler@student.tugraz.at>
To: Christina O'Donnell <cdo@mutix.org>, 68912@debbugs.gnu.org
Subject: bug#68912: Guix-home search paths shadow .config/guix/current
Date: Thu, 08 Feb 2024 10:07:28 +0100	[thread overview]
Message-ID: <23c2397e5ac73a5431e16d6fedaf007c5d92f400.camel@student.tugraz.at> (raw)
In-Reply-To: <7cd7e463-dfe5-4810-dc17-d1175e4696c3@mutix.org>

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




      reply	other threads:[~2024-02-08 12:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-03 13:12 bug#68912: Guix-home search paths shadow .config/guix/current Christina O'Donnell
2024-02-08  9:07 ` Liliana Marie Prikler [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=23c2397e5ac73a5431e16d6fedaf007c5d92f400.camel@student.tugraz.at \
    --to=liliana.prikler@student.tugraz.at \
    --cc=68912@debbugs.gnu.org \
    --cc=cdo@mutix.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).