etc/profile from Guix pack is a noop when $GUIX_PROFILE is defined
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?
Re: guix pull only from private channel
Hi, On Tue, 15 Dec 2020 at 19:29, Phil wrote: > 1) If the private channel is a git repo accessed via ssh it seems > necessary to add the ssh key to an ssh-agent rather than have it pick up > ~/.ssh/id_rsa. This isn't a huge problem but when the ssh key has no > passphrase the use of an agent is actually more complicated than passing > the key directly? Is it possible to specify a key file, and if not, is > there any good reason why not (I thought perhaps it might be access via > the guix-daemon or similar at a wild guess)? About this, I do not know. > 2) Assuming I use an ssh-agent to avoid issue in 1), if I want to only > pull updates from my private channel and not from the Guix channel, I > find myself doing something like the below to force Guix channel to stay > constant: > > eval `ssh-agent` && ssh-add && guix pull --commit=$(guix describe -f > json | jq -r '.[] | select(.name=="guix").commit') && guix upgrade > my-package-name > > This works, but it feels rather ugly - is there an easier way of saying > "hold guix constant, but pull in latest updates from my private > channel" - it feels like a common use-case to me? About this, you should write a specific channels.scm file and then run: guix pull -C channels.scm where the file is for example: --8<---cut here---start->8--- (use-modules (guix utils) (guix profiles) (guix channels) (guix openpgp)) (define guix (car %default-channels)) (define current (string-append (config-directory #:ensure? #f) "/current")) (define channels (profile-channels current)) (define defaults (filter (lambda (channel) (define (channel=? channel1 channel2) (equal? (channel-name channel1) (channel-name channel2))) (channel=? channel guix)) channels)) (append defaults (list (channel (name 'past) (url "https://gitlab.inria.fr/guix-hpc/guix-past.git";) (branch "master" --8<---cut here---end--->8--- Obviously, this is a quick example and you could filter as you want--here only with the channel name "guix". And this file could be in '~/.config/guix/channels.scm' and so "guix pull" would only pull everything except the channel named 'guix' which stays constant. Then to update the current 'guix' channel, you could have another file, for instance ~/.config/guix/default-channels.scm containing only one line with "%default-channels" and so "guix pull -C ~/.config/guix/default-channels.scm" would only update the default ones. The point is: instead of this ugly command line with ugly filtering, you should investigate in the Scheme API. :-) Hope that helps, simon
