On 2/1/26 23:14, pinoaffe wrote:
Hi Guix!
I think that doing this on a per-package level would turn
python-development in guix into a minefield: if this were to be adopted
and I then run
`guix shell python python-asdf python-qwer -- python3`
where asdf and qwer both depend on different versions of python-zxcv, I
*want* an error to occur
I agree. Please note that currently there is no warning.
E.g. python-numpysane needs numpy@1 and python-contourpy needs numpy@2.
(Example packages; I don't care about these specifically.) The packages
conflict when trying to install both:
$ guix install -n python-numpysane python-contourpy
The following packages would be installed:
python-contourpy 1.3.3
python-numpysane 0.42
guix install: error: profile contains conflicting entries for python-numpy
guix install: error: first entry: [email protected]
/gnu/store/y51kn69pfpblixx17sgagdj6a2i52czc-python-numpy-2.3.1
guix install: error: ... propagated from [email protected]
guix install: error: second entry: [email protected]
/gnu/store/vz6hlkxcgm8ybl3rgh4gpbhmjxra5vpw-python-numpy-1.26.4
guix install: error: ... propagated from [email protected]
But one can create a shell with both, apparently installing numpy@1:
$ guix shell --pure python python-pip python-numpysane python-contourpy
-- pip list
Package Version
---------- -------
contourpy 1.3.3
numpy 1.26.4
numpysane 0.42
pip 25.1.1
setuptools 80.9.0
I still don't understand the reason for this behavioral difference
between 'install' and 'shell'. I've learned that the difference is
intentional, but I don't know why.
So I always do a "guix install -n" before doing a "guix shell". This is
a poor user experience, IMO.
Therefore, it is in my opinion not sufficient to solve this on a
per-package basis: the fundamental idea of allowing several versions of
a python dependency in a single profile is a massive footgun, as other
packages aren't the only "consumers" of python APIs.
I like to highlight that it is not just "application" vs "development":
much of the Python ecosystem involves end-users writing Python code,
e.g. in notebooks. The REPL *is* the application.
To be clear: it will absolutely not be enough to give both
python-contourpy and python-numpysane their own python-numpy, because
the user (or third package) might want to share numpy arrays between
them, and that would probably not work. (And if it works for this
example, then it will be incidental.)
I would absolutely prefer not being able to install packages with
incompatible dependencies in the same profile. I can use different
profiles if I want to use both packages, as the packages won't work
together anyway.
Hugo
