Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Display alternative Python implementations in uv python list #7508

Closed
wants to merge 2 commits into from

Conversation

zanieb
Copy link
Member

@zanieb zanieb commented Sep 18, 2024

Closes #7286

We now show externally-managed alternative Python implementations

❯ ./target/debug/uv python list --only-installed
cpython-3.13.0rc2-macos-aarch64-none    /Users/zb/.local/share/uv/python/cpython-3.13.0rc2-macos-aarch64-none/bin/python3 -> python3.13
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.12.6-macos-aarch64-none       /Users/zb/.local/share/uv/python/cpython-3.12.6-macos-aarch64-none/bin/python3 -> 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.11.10-macos-aarch64-none      /Users/zb/.local/share/uv/python/cpython-3.11.10-macos-aarch64-none/bin/python3 -> python3.11
cpython-3.11.5-macos-aarch64-none       /Users/zb/.local/share/uv/python/cpython-3.11.5-macos-aarch64-none/bin/python3 -> 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
pypy-3.10.14-macos-aarch64-none         /Users/zb/.local/share/uv/python/pypy-3.10.14-macos-aarch64-none/bin/python3 -> pypy3.10

Previously, this required the implementation to use the python executable name. The problem here is that we weren't looking at these executables at all unless the alternative implementation was requested.

Comment on lines 918 to 920
// If found on the search path with the default executable name we should not skip it
&& !(installation.uses_default_executable_name()
&& installation.source == PythonSource::SearchPath)
Copy link
Member Author

@zanieb zanieb Sep 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit annoying, but necessary to prevent a regression when you have an alternative implementation on your PATH as python. We might want to track executable names in PythonSource::SearchPath directly; then we couple implement this in PythonSource::allows_alternative_implementations

Comment on lines 1528 to 1579
let implementation_names: Vec<&'static str> = implementation.map_or_else(
|| ImplementationName::possible_names().to_vec(),
|name| {
let name: &'static str = name.into();
vec![name]
},
);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @BurntSushi

This is the result of our failure to use an iterator here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improving this in #7649

@zanieb zanieb force-pushed the zb/pypy-fix branch 4 times, most recently from 65b41b4 to 522b7a5 Compare September 18, 2024 17:08
zanieb added a commit that referenced this pull request Sep 19, 2024
Follow-up to #7514 and #7526 adding
the `Any` variants again with slightly different semantics (i.e., they
allow pre-releases)

We'll be able to use this in #7508
to avoid querying a bunch of alternative interpreters unnecessarily in
the non-list case.
@zanieb
Copy link
Member Author

zanieb commented Sep 23, 2024

Moving some of this into #7649

zanieb added a commit that referenced this pull request 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/[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
@zanieb
Copy link
Member Author

zanieb commented Sep 23, 2024

I think this was fully superseded by #7517 and #7649

@zanieb zanieb closed this Sep 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

uv python list doesn't find pypy
1 participant