On 1/28/26 11:25, Steve George wrote:
On Tue, Jan 27, 2026 at 08:42:20PM +0100, Reza Housseini wrote:
Noé Lopez<[email protected]> writes:
Reza Housseini<[email protected]> writes:
(...)
One of the downsides is that guix python libraries would only work with
the guix version of the python interpreter, right?
Is it not already the case? GUIX_PYTHONPATH is not visible by a non-guix
python interpreter...
If you make it a GCD, then maybe you can have it be a cross-interpreter
solution?
Hmm worth while to think about it, although we have to fiddle with the
import intrinsics of Python which may not easily carry over to other
interpreters.
(...)
I guess we see this use-case in some of the other languages - I think I've seen
people asking about it with Rust at least. I guess it goes something like:
As a software developer I've installed multiple version of Python to test my
application. My application uses some libraries that are not packaged in Guix
and some that are packaged in Guix. How can I use the local interpreters and
local libraries.
Testing on multiple versions of Python is perhaps currently not
something you should use (just) Guix for.
One can't (generally speaking) use a library built for one Python with
another Python. It would work for pure Python packages, and I do
occasionally just set $PYTHONPATH to wherever I want to force
things, but that is bad form.
The proper way to test different Pythons is to create environments with
different Python versions and then install the to-be-tested package with
its dependencies in there. Usually people use one of the dozen
environment managers (uv being apparently the best now).
Technically, Guix could excel at making these environments, and I think
we should move towards that. But in practice, you'd want to test Python
3.13, 3.14, 3.15a, and those are not yet packaged by Guix at all.
If we do want to support something like, say, 5 different Python
versions, then we should have every package 5 times (not once and
reusing it, but we can inherit). Other package managers also have
different packages for each Python version.
So I don't think we have to take the
use-package-in-different-Pythons-reason as a strong argument against
this 'inputs'-proposal.
Maybe the situation is different in Rust, I don't know.
Hugo
