unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Kyle Andrews <kyle@posteo.net>
To: Julien Lepiller <julien@lepiller.eu>
Cc: Andy Tai <atai@atai.org>, help-guix@gnu.org
Subject: Re: guix running advice: correct?
Date: Sat, 04 Feb 2023 23:16:37 +0000	[thread overview]
Message-ID: <87bkm96m5f.fsf@posteo.net> (raw)
In-Reply-To: <F056FFC1-315E-4431-A2DF-181D53C5F2B9@lepiller.eu>


Julien Lepiller <julien@lepiller.eu> writes:

> Hi Andy,
>
> I'm the author of this advice. I think it's still correct. It's mostly
> sanity checks that you would run to ensure you can get packages from
> this channel. Most of it is scattered around the manual, mostly in the
> manual installation documentation.
>
> ~/.config/guix/current is where your new guix (the one you pulled with
> the channel) is installed. If it's not first in $PATH, you're at risk
> that some other guix will be used instead.
>
> hash is a command that removes an entry from the shell's cache. If
> this is your first pull, the guix you used comes from another location
> that is recorded by the shell, so you have to clear the cache to use
> the newly pulled guix. If your guix already comes from the correct
> location, it'll be useless but it won't hurt.
>
> HTH!
>
> Le 3 janvier 2023 06:31:25 GMT+01:00, Andy Tai <atai@atai.org> a écrit :
>>Hi, from this page
>>https://framagit.org/tyreunom/guix-android/-/blob/master/README.md
>>
>>Important checks
>>Make sure your guix environment is set up properly. You need to have
>>~/.config/guix/current as the first item in your $PATH or you're going
>>to run into troubles. Additionally, after running guix pull, make sure you
>>run hash guix in any open terminal to make sure bash's cache is cleared of
>>the old guix binary location.
>>
>>I wonder if the above is correct, as I do not recall seeing anything in
>>Guix doc mentioning such advice or something to that effect (unless I
>>missed it)

Interesting. I too had never heard about this PATH recommendation and it
seems contrary to some advice I do remember given in the cookbook about
working with multiple profiles. For me, activating an extra profile
places it's /bin and /sbin directories at the beginning of my PATH. I can
only find ~/.config/guix/current/bin burried quite deep near the end.

Do you have any advice on how regular end users could follow your
recommendation?

My naive hope would be that end users wouldn't have to think about
it. Ideally if its that dangerous then updating the path would happen
automatically when sourcing the etc/profile file inside a profile
directory.

Should the Guix Profiles in Practice section of the cookbook be updated
to reflect this?






  parent reply	other threads:[~2023-02-04 23:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-03  5:31 guix running advice: correct? Andy Tai
2023-01-04 17:08 ` Julien Lepiller
2023-01-04 18:41   ` Andy Tai
2023-02-04 23:16   ` Kyle Andrews [this message]
2023-02-05  6:41     ` Julien Lepiller

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=87bkm96m5f.fsf@posteo.net \
    --to=kyle@posteo.net \
    --cc=atai@atai.org \
    --cc=help-guix@gnu.org \
    --cc=julien@lepiller.eu \
    /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.
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).