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