Globally install multiple Python interpreters side by side

[sinoroc]

Is there a way to globally install multiple Python interpreters side by side?

I guess what I have in mind is maybe something similar to pipx install --suffix that allows installing multiple versions of the same application.

Or something like this:

pixi global install python=3.10
pixi global install python=3.11

By using pixi global, the very important side effect that I am after, is that pixi global upgrade-all would keep all my Python interpreters up-to-date very easily.

[pavelzw]

There are so-called features and environments in pixi which cover this use case. See here for the documentation and here for an implementation example that covers multiple Python versions (also notice how CI works there).

[pavelzw]

Would pixi runx solve this issue? #624

[ruben-arts]

I do think ideas of runx and global install serve two use-cases. But there are overlapping issues they both can solve.

e.g. with runx you could assume short lived solution and you would need pixi's cli to interact with the tools. While it makes sense to have multiple python versions globally available so you could do:

> python3.10 test.py
> python3.11 test.py

I think it makes sense that the global part of pixi allows for such a use case. But currently I would advice to indeed use your(@pavelzw) suggestion to build a pixi project and use the environments feature.

[sinoroc]

pixi global install -n python3.10 python==3.10

That sounds good. I think something like that would be fine.

But the main question would be is what python does python refer to?

In principle, personally I do not care that much, because I rarely use python or python3, unless I am in an isolated environment (conda or venv). But yes, of course I see how that could cause a lot of confusion. If I try to picture how I would implement this (in pixi), then I can not really think of a way to do this cleanly without risking unexpected behavior. As an aside, personally I think that is a real pity that we get the python, python3, and even python3.1 (?!?!) binaries, but I guess we have to deal with what we get, it would likely be very complex to get rid of those.

pixi runx python@3.12

Would something like that be cached somewhere? Or would the environment be recreated from scratch every time? If I were to alias python3.12 to pixi runx python@3.12, would it be quick enough on the subsequent runs?

[sinoroc]

Additional note, what is also quite important to me is the pixi global upgrade-all command to easily keep my Python interpreters up-to-date (I guess it could also be Node.js interpreters or whatever). So I guess that would exclude pixi runx.

[sinoroc]

Feels like the latest release candidate might be a very close match to what I had in mind. I have not tried it yet, though.

[liquidcarbon]

Would it work for you to have two local pythons and symlinks/shortcuts to them? Easy and predictable.

[sinoroc]

"Two separate pixi inits"? I am not following. Do you mind expanding on this, @liquidcarbon?

[liquidcarbon]

@sinoroc I guess it would help to expand a bit more on how you'd like to use the two pythons.

I was referring to this kind of setup. Suppose your ~/.local/bin is on PATH.

pixi init py310
pixi init py311
cd py310 && pixi add python=3.10 && ln -s $(pixi run which python) ~/.local/bin/python310 
cd ..
cd py311 && pixi add python=3.11 && ln -s $(pixi run which python) ~/.local/bin/python311

Now you have python3.10 and python3.11 globally available that are pointed to their own isolated environments.

Also check out #1097 - it's essentially recipe for two tiered environment where you'll have Pixi-managed outer environment and uv-managed inner environments.

[sinoroc]

@liquidcarbon, yes, it seems like in principle this would work. But quite a few steps involved. I am not sure pixi helps much in this scenario, though. Feels like, just Conda can do the same with with a roughly similar number and complexity of commands. Also no possibility of pixi global upgrade-all.

[liquidcarbon]

kind of like like Conda I suppose, but... faster?

When you say upgrade-all, what do you mean by all? python 3.11.7 to 3.11.8? Or the actual packages?
You can do a fresh install, any unpinned deps will go to their latest versions (however, some packages appear on conda forge with a delay, which is partly why I prefer something other than Pixi for installing python packages when versions matter)

[sinoroc]

When you say upgrade-all, what do you mean by all? python 3.11.7 to 3.11.8?

Yes, that is what I expect. And at at the same time during the same command run, for example: python3.12.1 to 3.12.2 as well.

kind of like like Conda I suppose, but... faster?

Faster? How? Why?

[sinoroc]

As far as I can tell for now, a solution like the following is (exactly) what I need:

pixi global install --environment=py39 --expose=python3.9 python=3.9
pixi global install --environment=py312 --expose=python3.12 python=3.12
pixi global install --environment=py313 --expose=python3.13 python=3.13

This looks like this in pixi-global.toml

version = 1

[envs.py39]
channels = ["conda-forge"]
dependencies = { python = "3.9.*" }
exposed = { "python3.9" = "python3.9" }

[envs.py312]
channels = ["conda-forge"]
dependencies = { python = "3.12.*" }
exposed = { "python3.12" = "python3.12" }

[envs.py313]
channels = ["conda-forge"]
dependencies = { python = "3.13.*" }
exposed = { "python3.13" = "python3.13" }

The features enabling this were added in v0.33.0. And the corresponding documentation was added in #2437.