Re: Replacing python venv - environment or profile?

[Phil]

Thanks Simon for the helpful comments - everything's hopefully clicked now - 
some
comments inline.


zimoun writes:


> Well roughly, an environment is a temporary profile.  So, in the Python
> terminology, the “environment” corresponds to the Guix profile.  And the
> Guix environment does not have an equivalent in the Python terminology,
> AFAIK.

Yes - I think it was the fact 'guix environment' had the '--pure' flag
that initially drew me in to consider this to be the parallel with
Python's virtual environment (and the original blog nudged me in that
direction too).

> To understand the difference between ’--pure’ or not:
>
>        $ guix environment --ad-hoc python
>  [env] $ echo $PATH
> vs
>        $ guix environment --ad-hoc python --pure
>  [env] $ echo $PATH
>
> And this is done for all the environment variables.

Yes this makes perfect sense to me, I guess what I was missing was that
a 'guix environment' is just a temporary and special case of sourcing a
Guix profile.

However the "--pure" switch means it has a useful feature that
originally I didn't appreciate was available when sourcing a profile by
using "--search-paths=exact" - note: the penny dropped for me below when 
reading your
e-mail, I've removed some of my own comments here about "--pure" now that I
understand it is not the only way to get a clean environment from a profile!

>   guix install python python-mypy -p ~/my-first-profile
>
>
> The big difference is “guix pull”.  Well, imagine this sequence:
>
>   guix environment --ad-hoc python
>   [..work..]
>   guix pull
>   guix environment --ad-hoc python
>
> Now, the first Python is not necessary the exact same than the second
> one.  Considering the sequence,

Yep you're creating two separate environments each taken from the
current 'latest' python version.  Which may have been updated by guix
pull for example.

>
>   guix install python -p /my-profile
>   [..work..]
>   guix pull
>   eval $(guix package --search-paths=prefix -p ~/my-profile)
>
> The Python inside your profile ~/my-profile has not changed.

Yes - I get this now.  The eval trick is nice.

>> $ guix environment --pure --manifest=manifest.scm --root=./test-profile
>
> I am not convinced you need the --root at first.

This is purely a way of creating a pure environment from a manifest, and
creating a profile from that same manifest as a one-liner (to pin the
packages in the store).  If you'd previously created a profile with the
same manifest this would be unnecessary.

> This create a environment, not a profile.  For a profile, you should do:
>
>   guix package -m manifest.scm -p ./test-profile

Yep - so this does the same thing as the above, but doesn't then put me
into a 'guix environment' referencing the same pacakges as the
test-profile does.

>
>> Finally.... I get to my question!  So in light of the above (assuming I
>> haven't missed the point completely!), what is the canonical way of
>> isolating a virtual environment using Guix on a foreign OS
>> installation?
>
> Profile and then the correct --search-paths.

Ah-ha! Now the penny has dropped - this was the piece of the puzzle I
had missed!

$ guix package --search-paths=exact -p ./test-profile
export PATH="./test-profile/bin"
export 
EMACSLOADPATH="./test-profile/share/emacs/site-lisp:./test-profile/share/emacs/27.1/lisp"
export INFOPATH="./test-profile/share/info"
export PYTHONPATH="./test-profile/lib/python3.8/site-packages"

So, if I instantiate the environment using "--search-paths=exact" then I
get *pure* environment variables, rather than appending or prepending to
the current variables.

So using this I don't need "guix environment --pure" anymore!  Which was
what I wanted.


> But if you want crazy isolation with container, you can do:
>
>   guix describe -f channels > my-channels.scm
>
> then any point in time, you will have the exact same environment with:
>
>   guix time-machine -C my-channels -- environment -C -m my-manifest.scm

This is snapshotting not just my manifest, but also the exact state of
the Guix commands themselves - so the environment and the tooling for
that environment are both replicated?


>
>> Last point - ultimately as well as using Guix to provide a consistent
>> profile/environment to do Python work in, I'd ultimately
>> like to hook Guix up to Jenkins so that it can package and deploy a
>> repo to a
>
> That’s a bigger story…

Yes agreed - let's discuss later, I just wanted to give the group a
vague idea of where I'm hopefully ultimately heading with my Guix use,
but I must walk before I run!