python: rtx should behave consistenly with either asdf or pyenv if the Python's system version is set along with other versions

[SergiyKolesnikov]

rtx behaves differently from asdf and pyenv if Python's system version is configured along with additionally installed versions. (Similar issue #831)

Pyenv allows to use all versions:

root@62c8cadea516:~# pyenv global system 3.10.0 3.9.0  # system version is 3.11.2
root@62c8cadea516:~# pyenv versions
* system (set by /root/.pyenv/version)
* 3.9.0 (set by /root/.pyenv/version)
* 3.10.0 (set by /root/.pyenv/version)
root@62c8cadea516:~# python3
Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
root@62c8cadea516:~# python3.9
Python 3.9.0 (default, Sep 19 2023, 15:07:31) 
[GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 

root@62c8cadea516:~# python3.10
Python 3.10.0 (default, Sep 19 2023, 15:08:33) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 

asdf only allows the system version:

root@98589602479a:~# cat ~/.tool-versions   # system version is 3.11.2
python system 3.10.0 3.9.0
root@98589602479a:~# python3
Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
root@98589602479a:~# python3.10
No python3.10 executable found for python system
root@98589602479a:~# python3.9 
No python3.9 executable found for python system
root@98589602479a:~# python3
python3            python3.10         python3.10-gdb.py  python3.9          python3.9-gdb.py   
python3-config     python3.10-config  python3.11         python3.9-config   
root@98589602479a:~# python3

rtx allows all but the system version (unless called explicitly through the versioned binary):

root@ec798d93b5bc:~# cat ~/.config/rtx/config.toml 
[tools]
python = ["system", "3.10", "3.9"]
root@ec798d93b5bc:~# python3
Python 3.10.13 (main, Sep 19 2023, 09:10:19) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
root@ec798d93b5bc:~# python3.10
Python 3.10.13 (main, Sep 19 2023, 09:10:19) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
root@ec798d93b5bc:~# python3.9 
Python 3.9.18 (main, Sep 19 2023, 09:11:18) 
[GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
root@ec798d93b5bc:~# python3.11
Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
root@ec798d93b5bc:~# which python3.11
/usr/bin/python3.11

For all these behaviors, the behavior of pyenv is the one of least surprise. It is also useful, because it allows to preserver the system Python version as default for programs that rely on it (for example, those installed with the system package manager) and at the same time allow "smart" tools that can use versioned Python binaries do their magic. For example, poetry knows which version of Python is needed for a given project and can look for the corresponding versioned Python binary, so there is no need in .tool-versions.

[jdx]

"system" (in both pyenv and rtx) imply a no-op. This means it will just use whatever binaries is on PATH. However in the case of python if you have multiple versions installed I have no way to know that something like python3.9 shouldn't be used from a different version. I'm not actually sure how pyenv gets around this issue.

I don't know how this could be solved short of hardcoding binary names which I don't think is something I would want to do.

[AndydeCleyre]

I'm unclear on how it's expected to work with multiple versions in Python -- I came to this issue now because I need all installed versions available by name, but they're not.

(zsh)

$ grep python ~/.config/mise/config.toml
python = "latest"
$ cat .tool-versions 
python 3.13 3.12 3.11 3.10 3.9 3.8 3.7
$ mise install
mise all runtimes are installed
$ ls ~/.local/share/mise/installs/python
3
3.10
3.10.14
3.10.15
3.11
3.11.10
3.11.8
3.12
3.12.2
3.12.7
3.13-dev
3.7
3.7.17
3.7.9
3.8
3.8.19
3.8.20
3.9
3.9.19
3.9.20
latest
$ print -rl -- $path | grep mise
/home/andy/.local/share/mise/installs/python/3.11.10/bin
/home/andy/.local/share/mise/installs/hyperfine/latest/bin
/home/andy/.local/share/mise/installs/usage/latest/bin
/home/andy/.local/share/mise/installs/shellcheck/latest/bin
/home/andy/.local/share/mise/installs/lua/latest/bin
/home/andy/.local/share/mise/installs/lua/latest/luarocks/bin
/home/andy/.local/share/mise/installs/just/latest/bin

[jdx]

What about mise ls?

[AndydeCleyre]

Well today all the relevant paths are present, and it works as I'd hope:

$ print -rl -- $path | grep 'mise.*python'
/home/andy/.local/share/mise/installs/python/3.12/bin
/home/andy/.local/share/mise/installs/python/3.11/bin
/home/andy/.local/share/mise/installs/python/3.10/bin
/home/andy/.local/share/mise/installs/python/3.9/bin
/home/andy/.local/share/mise/installs/python/3.8/bin
/home/andy/.local/share/mise/installs/python/3.7/bin

So as long as that's what you expect, and this is how it continues to act, I'm just adding noise here -- sorry!