Add an ArchMode to filter displayed architectures in uv python list#13701
Add an ArchMode to filter displayed architectures in uv python list#13701
ArchMode to filter displayed architectures in uv python list#13701Conversation
zanieb
force-pushed
the
zb/arch-mode
branch
2 times, most recently
from
6c775c9 to
710c515
Compare
zanieb
force-pushed
the
zb/arch-mode
branch
4 times, most recently
from
05782d0 to
b27ef41
Compare
|
Eek, this is actually quite hard. |
zanieb
force-pushed
the
zb/arch-mode
branch
2 times, most recently
from
cb2dc54 to
149a812
Compare
|
The ordering actually needs to change, per #13474 (comment), see #13709 |
|
Need to make sure this reconciles with #13719 |
|
Hmm in my heart we want to be internally producing a 2d list of pythons:
And then unless the user asks we only show the top entry in each one. I'm not sure if that would be too disruptive architecturally. |
|
Another subtlety: if the user does have a copy of python installed that is compatible but for whatever reason not preferred, we should probably still show it in |
We will! This is just for listing available downloads and selection of downloads for installation. |
I think the arm Windows case is a bit of a separate concern. It's also plausible people will build wheels for older CPython versions on arm once it's commonplace, so it's not clear if we'll need that matrix yet. |
|
Right I've been confused why the tests were failing in those other PRs given we already do a ton of special filtering, and I think I just realized you might just be working around a bug in the filtering at the end of list? |
|
Put up an alternative here: #13721 |
|
The alternative was convincing for now. |
2 participants
I'm trying to unblock
which currently fail due to showing more downloads in
uv python listand selecting non-native installs duringuv python install. I don't really want to show non-native downloads without opt-in (it'll just be too noisy), and we should prefer native installs, so this pull request adds a change to apply some filtering. This should have no effect on the existing behavior, but will resolve the failing CI in those pull requests.Note, the modes do not yet capture the semantics we'll need for arm64 Windows, but I'll try to figure that out afterwards.
This is a little forward-looking, in that it adds support for filtering based on architecture variants as needed for
That pull request is currently blocked on allowing the user to express they only want to use
x86-64-v1even if they have av3compatible machine. I expect the spelling of the options for "best" and "compatible" native architectures to change a little.I don't make this user-facing here, but we probably will in a subsequent change.