Replacing python venv - environment or profile?

[Phil]

Hi all,

Apologies this is a bit longer than I anticipated, but I wanted to record
all the steps I'd taken to explain my reasoning - in case it's wrong!

I'm new the Guix and considering adopting it as an expansion to my
current use of Python virtual environments in development and
production, to include other non-Python packages too.

The potential of the software is very exciting!

I've read the manual/cookbook and I get the gist of the tool.  One thing
I'm getting a bit stuck on is the appropriate use of environment vs
profile; different sources give slightly different takes on the theme, and I
want to make sure my use is correct from the get-go.

I'll be using Guix on a foreign OS, I suspect the answers might be
slightly different if I was able to adopt the Guix System OS, but for
now I can't.

As well as the manual cookbook I came across this blog:
https://trivialfis.github.io/linux/2018/06/10/Using-guix-for-development.html

This is describing the use of 'guix environment' and manifests to create a
structure very similar to a python virtual environment, but including
the python package itself too.  Which is exactly the starting point I had in 
mind.

I understand that I can use the --pure switch to ensure no pollution
from the foreign OS programs - just like the default behaviour of python venv, 
eg:

ubuntu@primary:~$ guix environment --ad-hoc coreutils --pure

ubuntu@primary:~$ ls
dev
ubuntu@primary:~$ nano
Command 'nano' is available in the following places
 * /bin/nano
 * /usr/bin/nano
The command could not be located because '/bin:/usr/bin' is not included in the 
PATH environment variable.
nano: command not found


This is great - but the manual points out that none of the
installed packages are marked such that they avoid garbage collection.

So I came up with something like the below - manifests do seem to be an
exact analogy to Python requirements.txt files:

$ cat manifest.scm 
(specifications->manifest
  '("coreutils"
    "emacs@27.1"
    "python"
    "python-pytest"
    "python-coverage"
    "python-pytest-cov"
    "python-black"
    "python-mypy"
    "python-flake8"))
$ guix environment --pure --manifest=manifest.scm --root=./test-profile

This creates a profile as a side-effect, I think.

This would be all well and good but both the manual and the cookbook,
and a few other sources I've found online seem to equate a *profile* with
a virtualenv rather than use of the *guix environment* command.

To test this as an alternative, I source the profile created by the manifest 
above:

$ export GUIX_PROFILE=/home/ubuntu/dev/test-profile
$ . $GUIX_PROFILE/etc/profile

I note that unlike the environment which creates what I assume is its
own temporary profile, eg:

$ echo $PATH
/gnu/store/hchmga9ybpdc4zph9cs8jr7m1k8gxw9f-profile/bin

Sourcing the created profile references both it, the default profile,
and guix's profile, followed by the foreign OS PATH variables:

$ echo $PATH
/home/ubuntu/dev/test-profile/bin:/home/ubuntu/.guix-profile/bin:/home/ubuntu/.config/guix/current/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin


I'm keen to avoid accidentally calling anything in the foreign OS,
something the 'guix environment' command gives me, but obviously the foreign
OS will serve as a fallback given the above PATH construction under a sourced
profile.  So if my profile doesn't have python installed, but it is part
of the foreign OS, I would silently pick that up, which would be bad.


As per 4.1.1 in the cookbook I can avoid setting other profiles using:

$ env -i $(which bash) --login --noprofile --norc
$ export GUIX_PROFILE=/home/ubuntu/dev/test-profile
$ . $GUIX_PROFILE/etc/profile

But the foreign OS variables remain:

$ echo $PATH
/home/ubuntu/dev/test-profile/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ 

So to my mind Guix profiles are more like Python virtual environments with
the with the non-standard --system-site-packages switch than the classic
use of Python virtual environment?  Useful, but different.  The 'guix
environment' is accidentally providing a closer parallel.

I'm guessing that if I used the Guix System OS the profile analogy would be much
more accurate as there would be no foreign OS to fallback onto?

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?

Is the use of 'guix environment' as per the blog referenced above
considered good practice, or is this as I now suspect, inappropriate 
re-purposing of a
feature designed to create transient environments for building/debugging 
specific
programs packaged in Guix?

Links such as this suggest this might be the case:
https://yhetil.org/guix-user/1700d451826.11317682011034.4058430466276292306@zoho.com/T/

Of course I could probably write a script that scrubs my own
environment variables of all references to the foreign OS, but this feels
like I'm doing what I thought I'd get for free with Guix in the first
place?

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
production server.  This probably involves setting-up a private Guix
Channel and importing built wheels, and to then pull the new Guix package from 
the
production server.  Ultimately tho I'd want the same thing - a pure
environment in production which has access to exactly and only the
software as described in the manifest.  This feels like it should be
possible too, but again, just looking for any initial guidance on which features
of Guix to use to do this.

Sorry for the long e-mail, and thanks in advance for any guidance
or advice on the matter!


Cheers,
Phil.