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" "[email protected]" "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/[email protected]/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.
