unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: EuAndreh <eu@euandre.org>
To: help-guix <Help-Guix@gnu.org>
Subject: etc/profile from Guix pack is a noop when $GUIX_PROFILE is defined
Date: Wed, 16 Dec 2020 14:21:51 -0300	[thread overview]
Message-ID: <87a6ud8y4w.fsf@euandre.org> (raw)

Hi Guix!

In a chat with civodul on IRC the other day we discussed about the
generated etc/profile profile created by the "guix pack" command.  It is
my understanding that it falls just a very tiny bit short on making
tarballs a great application bundle.  This happens because of how
$GUIX_PROFILE is treated on the generated profile.  Here's the output of
an interactive session:

--8<---------------cut here---------------start------------->8---
$ echo $GUIX_PROFILE
/home/andreh/.config/guix/current
$ tar xf `guix pack -RR -S /bin=bin -S /etc=etc guile gnutls guile-json`
$ cat etc/profile
# Source this file to define all the relevant environment variables in Bash
# for this profile.  You may want to define the 'GUIX_PROFILE' environment
# variable to point to the "visible" name of the profile, like this:
#
#  GUIX_PROFILE=/path/to/profile ; \
#  source /path/to/profile/etc/profile
#
# When GUIX_PROFILE is undefined, the various environment variables refer
# to this specific profile generation.

export PATH="${GUIX_PROFILE:-/gnu/store/8yjf5dypd0fw3va2y5hfdigfjxr6fpy6-profile}/bin${PATH:+:}$PATH"
export GUILE_LOAD_PATH="${GUIX_PROFILE:-/gnu/store/8yjf5dypd0fw3va2y5hfdigfjxr6fpy6-profile}/share/guile/site/3.0${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH"
export GUILE_LOAD_COMPILED_PATH="${GUIX_PROFILE:-/gnu/store/8yjf5dypd0fw3va2y5hfdigfjxr6fpy6-profile}/lib/guile/3.0/site-ccache:${GUIX_PROFILE:-/gnu/store/8yjf5dypd0fw3va2y5hfdigfjxr6fpy6-profile}/share/guile/site/3.0${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPILED_PATH"
$ echo $GUILE_LOAD_PATH
/home/andreh/.config/guix/current/share/guile/site/3.0
$ source etc/profile
$ echo $GUILE_LOAD_PATH
/home/andreh/.config/guix/current/share/guile/site/3.0:/home/andreh/.config/guix/current/share/guile/site/3.0
$ GUIX_PROFILE= source etc/profile
$ echo $GUILE_LOAD_PATH
/gnu/store/8yjf5dypd0fw3va2y5hfdigfjxr6fpy6-profile/share/guile/site/3.0:/home/andreh/.config/guix/current/share/guile/site/3.0:/home/andreh/.config/guix/current/share/guile/site/3.0
--8<---------------cut here---------------end--------------->8---

By using $GUIX_PROFILE and falling back to the /gnu/store/...-profile
path, the environment variables declarations won't work in a case: when
$GUIX_PROFILE is already defined.  In my case, what ended up happening
is that $GUILE_LOAD_PATH wasn't being enriched by the file, and ended up
with a duplicate entry of $HOME/.config/guix/current.  I was able to
achieve the desired behaviour by making $GUIX_PROFILE undefined, but it
felt like a pitfall to me.  I was left with the impression that this
wasn't the desired behaviour.

My previous mental model was that I could take a tarball generated by
"guix pack", source the profile and the binaries would be added to
$PATH.  Now I feel I have to remember this detail: remember to prefix
the "source" command with "GUIX_PROFILE= ", and this should work
regardless of the environment.

Is this the desired behaviour? Am I missing something?


                 reply	other threads:[~2020-12-16 18:01 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=87a6ud8y4w.fsf@euandre.org \
    --to=eu@euandre.org \
    --cc=Help-Guix@gnu.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.
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).