`uv tool install smth` picks the "worst" Python

[dimaqq]

Summary

I've managed to corner my machine to a setup, where uv tool install appears to select the "worst" Python:

• Python3.9 (from the OS?) at /usr/bin/python3
• Python3.10 (from Python.org) as /usr/local/bin/python3
• Python3.11, 3.12, 3.13, 3.13t, 3.14, 3.14t, 3.15, 3.15t (from Python.org) in /usr/local
• no modern pythons installed using uv python install
• Python3.8 installed using us python install 3.8

Note that uv python list sees all of these options.

In this config, uv tool install tox --with tox-uv installs the tool using Python 3.8, which leads to ancient tox-uv dep being used (also it's slow, but whatever).

And tox with the ancient plugin fails with tox-dev/tox-uv#230

Is it something I did to myself?
Yes.

Is it something another developer could run into?
Yes, because when the system doesn't provide some old python and I gotta run tests in some older project, I'd end up uv python install-ing that old version.
Now I'm getting hit because of that and quite unexpectedly.

Work-arounds:

• either uv tool install -p 3.12 tox --with tox-uv or 3.10 or whatever is not EOL
• or uv python install 3.12; uv tool uninstall --all; uv tool install ..., then that gets picked.

So.. it's a bit of a foot-gun.
Could uv perhaps understand which Python versions are EOL?

Platform

macos

Version

uv 0.10.4 (Homebrew 2026-02-17)

Python version

Python 3.10.11

[dimaqq]

I suppose preferring a system Python is something that has been decided against in this project, because it could disappear and leave the tool venvs broken, hasn't it?

[konstin]

When the user doesn't specify a Python version in the command or selects one with uv python pin --global, uv needs to guess what the preferred Python version of the user is. For this, it uses the first Python in PATH: It's the Python that gets run with python, so we assume that it's the user's preference. This isn't ideal, especially in combination with uv python install 3.8, but unless you use uv python pin to pick a specific one as your default, uv doesn't have a better default to pick.

We can't use EOL status to determine this, otherwise we risk time-based breaking on workflows when a version becomes EOL. Regarding the system Python, there's many linux distros that ship with an ancient Python version, possibly already EOL while the distro is still supported, so switching to system Python by default wouldn't fix this either.

[dimaqq]

In my case, there's no pinned global or project Python:

> uv python pin --global
error: No Python version file found; specify a version to create one

And first-in-path logic doesn't seem quite right:

> echo $PATH
/Library/Frameworks/Python.framework/Versions/3.10/bin /Users/dima/.rd/bin /Library/Frame...

I imagine that uv modifies the PATH for itself perhaps?

[konstin]

Can you share verbose logs (-v, or -vv if that doesn't have enough details)? Those trace how uv decided which Python version to use.