uv python list doesn't find pypy #7286
Assignees
Comments
hynek
changed the title
|
That's surprising. I'll look into this. |
zanieb
added
bug
|
Btw if you don't want to see the downloads you can use |
Ohhh loving it! I didn’t mind the download available but this is really cool. |
|
I think this is because, generally, we don't look for |
|
That’s kinda funny in combination with #7118 — sorry for running into all edge cases. 🙈 |
|
I appreciate it :) |
|
|
This was referenced Sep 18, 2024
zanieb
added a commit
that referenced
this issue
Sep 19, 2024
As we support more complex Python discovery behaviors such as: - #7431 - #7335 - #7300 `Any` is no longer accurate, we actually are looking for a reasonable default Python version to use which may exclude the first one we find. Separately, we need the idea of `Any` to improve behavior when listing versions (e.g., #7286) where we do actually want to match _any_ Python version. As a first step, we'll rename `Any` to `Default`. Then, we'll introduce a new `Any` that actually behaves as we'd expect.
zanieb
added a commit
that referenced
this issue
Sep 23, 2024
…mentations (#7649) 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/python@3.12/bin/python3.12 -> ../Frameworks/Python.framework/Versions/3.12/bin/python3.12 cpython-3.11.10-macos-aarch64-none /opt/homebrew/opt/python@3.11/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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I find
uv python listan amazing tool to debug Python Environment xkcd situations, even tho I don't use uv for downloads. But find my PyPy installation (I could've sworn it used to but I might be wrong).Here's le output to demonstrate:
I can use it to create venvs, though:
The text was updated successfully, but these errors were encountered: