Re: No Explicit Python Version Dependency In Package Definitions?

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 4093 bytes --]


Phil <phil@beadling.co.uk> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]