Improve Python executable name discovery when using alternative implementations

[zanieb]

There are two parts to this.

The first is a restructuring and refactoring. We had some debt around expected executable name generation, which we address here by consolidating into a single function that generates a combination of names. This includes a bit of extra code around free-threaded variants because this was written on top of #7431 — I'll rebase that on top of this.

The second addresses some bugs around alternative implementations. Notably, uv python list does not discovery executables with alternative implementation names. Now, we properly generate all of the executable names for VersionRequest::Any (originally implemented in #7508) to properly show all the implementations we can find:

❯ cargo run -q -- python list --no-python-downloads
cpython-3.12.6-macos-aarch64-none     /opt/homebrew/opt/[email protected]/bin/python3.12 -> ../Frameworks/Python.framework/Versions/3.12/bin/python3.12
cpython-3.11.10-macos-aarch64-none    /opt/homebrew/opt/[email protected]/bin/python3.11 -> ../Frameworks/Python.framework/Versions/3.11/bin/python3.11
cpython-3.9.6-macos-aarch64-none      /Library/Developer/CommandLineTools/usr/bin/python3 -> ../../Library/Frameworks/Python3.framework/Versions/3.9/bin/python3
pypy-3.10.14-macos-aarch64-none       /opt/homebrew/bin/pypy3 -> ../Cellar/pypy3.10/7.3.17/bin/pypy3

While doing both of these changes, I ended up changing the priority of interpreter discovery slightly. For example, given that the executables are in the same directory, do we query python or python3.10 first when you request --python 3.10? Previously, we'd check python3.10 but I think that was an incorrect optimization. I think we should always prefer the bare name (i.e. python) first. Similarly, this applies to python and an executable for an alternative implementation like pypy. If it's not compatible with the request, we'll skip it anyway. We might have to query more interpreters with this approach but it seems rare.

Closes #7286 superseding #7508

[charliermarsh]

Confirming my understanding: given the logic right above this, does that mean --python 3.12a0 will major 3.12.1 (stable), as an example?

[zanieb]

Sorry I don't follow, I think there's something missing from your comment.

[charliermarsh]

Will --python 3.12a0 match a Python interpreter with version 3.12.0?

[zanieb]

There should be no changes to interpreter match checks here, just the executable names we consider when querying. So yeah --python 3.12a0 will result in us querying a Python executable with the name python3.12 and python3.12.0 etc. but I don't think we will use it if its version isn't actually 3.12.0a0

[charliermarsh]

So if the user runs --python 3.10, we query python for its metadata, and if it's a different version, we continue checking the next interpreter, etc.? I assume this was already true, and this PR just inverts the order such that python is first, per the summary. What's the motivation for that, though? When would it be incorrect?

[charliermarsh]

I don't know if the borrow checker will let you, but if so, it might be a bit easier to write this with an iterator (like names.extend(...)) so that it's guaranteed that it doesn't loop infinitely (despite modifying names).

[zanieb]

I think I could rewrite some of these as iterators, but I fought with the borrow checker a lot in here and I'd prefer to keep it simple. for i in 0..names.len() seems guaranteed to never loop infinitely since the range is evaluated at the start.

[charliermarsh]

What's the motivation for splitting these up? (Is it functional?)

[charliermarsh]

Oh I see, you use long_names elsewhere (per PR summary, to find pypy).

[zanieb]

Yeah, e.g., we don't want to look for interpreters with executables named cp but cp is a valid request name when parsing so I had to separate them.

[charliermarsh]

So this adds... pypy, pypy3, etc.?

[zanieb]

Yep! For each implementation.

[zanieb]

So if the user runs --python 3.10, we query python for its metadata, and if it's a different version, we continue checking the next interpreter, etc.? I assume this was already true, and this PR just inverts the order such that python is first, per the summary. What's the motivation for that, though? When would it be incorrect?

Yes, this was already true. The things that's changing here is the order of interpreters queried within a single directory. The motivation is consistency and simplicity. It's more complicated to explain and to implement if we want to change the ordering depending on the request given, especially as we add more variants of requests. Here, the ordering is consistent across all requests, we just include more names depending on the request. The motivation for having the original ordering was that it could be more performant to check python3.10 before python if Python 3.10 was requested.

As an elucidating case, if you have python which is Python 3.10.1 and python3.10 which is Python 3.10.2 and ran python in your shell you'd get 3.10.1. Generally the feedback we've gotten is that we should do our best to prioritize matching the experience of running python from the shell so I think it's more "correct" to use check python first but it's pretty ambiguous what the proper resolution order is there so I want to do what's simplest.

[zanieb]

I'm going to merge because it's blocking some other work, but if you have any concerns following this I'm happy to talk through them.