uv store proposer can resolve a bare version spec to PyPy, in arbitrary order #110

Not sure what your thoughts might be on this one, but adding it here just in case you'd like to change it. Also came out of the investigation for wntrblm/nox#1139.

🤖 AI text below 🤖

Problem

_propose_from_uv globs */bin/python, which also matches PyPy installs in the uv store (pypy-3.8.16-.../bin/python exists). Candidates are yielded in filesystem glob order, unsorted. Combined with a bare version spec (no implementation constraint), this means get_interpreter("3.8") can return PyPy even when a CPython 3.8 sits in the same store:

# macOS, python-discovery 1.5.0, ~/.local/bin removed from PATH,
# UV_PYTHON_INSTALL_DIR pointed at the real store (see #109)
get_interpreter('3.8')
# -> ~/.local/share/uv/python/pypy-3.8.16-macos-aarch64-none/bin/python
get_interpreter('cpython3.8')
# -> ~/.local/share/uv/python/cpython-3.8-macos-aarch64-none/bin/python

A bare spec matching any implementation may be intended, but on PATH the equivalent search probes python3.8-style names, which in practice resolve to CPython — the uv store proposer makes the loose match user-visible for the first time, and nondeterministically (glob order decides among multiple matching installs).

Suggested fix

Parse the store directory names (<impl>-<version>-<platform> is a stable uv contract) to filter and sort candidates before probing: prefer CPython for bare specs — matching uv's own semantics, where 3.8 means cpython-3.8 — and probe in descending version order so the newest matching install wins deterministically. This would also avoid spawning every store interpreter just to test a spec that its directory name already rules out.

Found while investigating wntrblm/nox#1139.