Re: [Blog/Cookbook?] On multiple Guix profiles and manifests

[Chris Marusich]

Pierre Neidhardt <address@hidden> writes:

>> However, I wonder why nobody has implemented
>> "guix environment --profile=/path/to/my/profile".
>
> Note that there is the "--manifest" option to "guix environment".
>
> This brings up another "pro" for manifest: Right now it's possible to
> create environments out of manifests while it's not possible to create
> environments out of profiles without Chris' hack.

This is true.  However, in practice, I often wind up in this sort of
situation:

1.  I want an environment for hacking on a project for which there isn't
a Guix package yet.  I build the environment using a manifest, and then
I run "guix environment -m manifest.scm".  Great!
2.  Many weeks or months pass as I work on other things.
3.  I run "guix pull" at some point.
3.  Eventually, I want to work on that project again, so I run "guix
environment -m manifest.scm".  But now I have to wait hours for Guix to
build and install stuff!

In this situation, if I could just "enter the environment for a
profile", I wouldn't have to wait for Guix to recompile the world.  With
"guix environment -m manifest.scm", you have to wait for the latest
version of everything to be built.  I realize that you could roll back
your Guix installation to whatever version was being used back then (do
you even remember when it was?  I often forget...) and then "guix
environment" ought to work (unless the outputs were GC'd in the
meantime), but I don't think that's a very viable solution because it
requires the user to remember what version was in use at the time and to
take the extra steps necessary to rollback the Guix installation first.
For that reason, I like your suggestion of using "GUIX_PROFILE=profile;
. $GUIX_PROFILE/etc/profile" better.  It requires no waiting, and
because it's a profile you get easy per-profile roll-back.

Pierre Neidhardt <address@hidden> writes:

> A question that I believe has been brought up before: is it possible to
> specify multiple manifests from the command line, such as to provide the
> union of the manifests?

Not sure - I don't think it is possible on the CLI right now.

> Even better: what high-level functions to manipulate manifests, such as
> "manifest-union", "manifest-difference"?

I'm not sure what I would personally use "manifest-difference" for.

>> guix-profile-env()
>> {
>>     if [ -z "$1" ]; then
>>         echo "usage: guix-profile-env PROFILE [CMD [ARG ...]]" 2>&1
>>         return 2
>>     fi
>>     local sh
>>     sh="${SHELL:-/bin/sh}"
>>     if [ -z "$2" ]; then
>>         "$sh" \
>>         -c \
>>         'GUIX_PROFILE="$0" && . "$0"/etc/profile && exec "$1"' \
>
> Shouldn't it be '"$1"/etc/profile'?  And no "exec ..."?

There are two shells.  One is the calling shell, the second is the "$sh"
shell.  The $0 expands to the first argument because it is invoked with
-c (see: (bash) Special Parameters), which in this case is the profile.

>>         "$1" \
>>         "$sh"
>>     else
>>         "$sh" \
>>         -c \
>>         'GUIX_PROFILE="$0" && . "$0"/etc/profile && exec "$@"' \
>>         "$@"
>
> Can you explain why you need to repeat $@ here?

Here, the first "$@" is expanded by the second shell ("$sh").  The
second "$@" is expanded by the calling shell.  You might think we could
write it like this:

  "$sh" \
  -c \
  "GUIX_PROFILE=\"$1\" && . \"$1\"/etc/profile && exec $@"

If we did that, then $1 and $@ are expanded by the calling shell, and
the second shell doesn't do any parameter expansion at all.  However,
this would not work as intended if the elements of $@ (i.e., the CMD and
its ARGs) ever contained whitespace, since the second shell would
perform word splitting (see: (bash) Word Splitting) on them.  To avoid
that, it is necessary to have the second shell expand $@ within
quotation marks (see: (bash) Special Parameters), which is how I
originally wrote it.

In the end, this is still just a hack, and I think it would be nicer to
have a command like "guix environment --profile=/my/profile" to make it
even simpler to use.  Perhaps I will give an implementation a try.

-- 
Chris

signature.asc
Description: PGP signature