Phil writes: > Thanks for the reply. > > Christopher Baines writes: > >> Build systems are a mechanic to deduplicate common steps, but also >> common inputs between packages, and the python-build-system will include >> a default Python as an input. >> >> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build-system/python.scm#n138 > > Got it - so the version is set behind the scenes depending on the > current python package definition. > >> So, you can't have this particular python-scipy output in your store >> without python as well, as it's referenced by some shared libraries, >> which I guess makes sense. > > Yep - so even tho python 3.8 is not installed by installing eg > python-scipy, the package is made available in the store as it's referenced. > >> When the default python version is changed, the build system will change >> accordingly. > > Yep makes sense - so the python package will now reference the 3.9 > package here instead of 3.8: > > ;; Current 3.x version. > (define-public python-3 python-3.8) > > I'm guessing my local Guix would stay on 3.8 until I did a guix > upgrade. At this point the new version of python-3 would force any > python packages I had to reinstall against 3.9. I assume my local 3.8 system > would be left untouched, such that I could rollback both the python > version and my packages if I wanted? What you say is roughly right, but it's not very representative of what happens. Upgrading to Guix that has Python 3.9 as the default from a version where 3.8 is the default will affect the build system behaviour as you've seen. Upgrading your profile will generate you a new generation where the Python packages are built with 3.9 (as that's what the updated Guix provides). Changes to profiles are not destructive, so you can roll back. > What would happen if I installed a new python package after pulling the > latest package definitions tho? Guix profiles work with search paths, and the PYTHONPATH is version specifc, so python@3.9 will look in lib/python3.9/site-packages. You can see this in action here: → guix environment --ad-hoc python python-pandas --search-paths export PATH="/gnu/store/08y11hsyflh1fdpkvs8f8snydkr9vq36-profile/bin${PATH:+:}$PATH" export PYTHONPATH="/gnu/store/08y11hsyflh1fdpkvs8f8snydkr9vq36-profile/lib/python3.8/site-packages${PYTHONPATH:+:}$PYTHONPATH" If you have a python@3.8 plus one python library built with python@3.8 and another python library built with python@3.9, the PYTHONPATH Guix generates will just include lib/python3.8/site-packages. > So I have a system say with python3.8 and python-scipy, and I decide I > want to then install python-pandas (for example). Will it not then > build this for python 3.9 (due to the new definition), if the version of > python has incremented between the installs of python-scipy and > python-pandas? Would I then have to manually reinstall python-scipy to > have it under 3.9 (as well as 3.8) (or do a guix upgrade)? Yep. > Last question, if today I wanted to create a profile that installed > python-scipy against the python 3.9 package definition (which already > exists in Guix it's just not the default). Do I have to change the > python-3 definition as per above, or is there another way of saying "use > python3.9 just for this profile". You can pass the python package to use to the python-build-system through the #:python argument. Look for examples of this in Guix, there's plenty for Python 2 only libraries. There are quite a few transformation options that you can use when building/installing packages, but I'm not aware of one that works with build system arguments. Maybe that could be added though. Without that, you'd need to either change the default python, or generate a variant of the library which uses the python you intend. > I suspect I could use a manifest to install 3.9 rather than the default, > but won't any packages still depend on 3.8 unless I switch the python-3 > definition? Yes.