Re: Replacing python venv - environment or profile?

[Christopher Lam]

No constructive comments here, except a thank you for sharing an
incremental tutorial on using guix.

Sorely needed:
- similar incremental tutorial for C based projects.
- similar tutorial for other text editors eg vscode


On Tue, 24 Nov 2020 at 18:35, Phil <phil@beadling.co.uk> wrote:

> 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.
>
>