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!
