Disallow arm64 Windows Python installs for now#13719
Closed
geofft wants to merge 1 commit intoastral-sh:mainfrom
Closed
Disallow arm64 Windows Python installs for now#13719geofft wants to merge 1 commit intoastral-sh:mainfrom
geofft wants to merge 1 commit intoastral-sh:mainfrom
Conversation
See astral-sh#12906 and astral-sh/python-build-standalone#387 - as soon as we start shipping arm64 Windows Python builds in python-build-standalone, uv is going to start discovering them, and there aren't enough arm64 Windows wheels for that to make sense as a default yet. As a very minimal stopgap, consider those builds incompatible. No functional change expected at the moment, but this unblocks python-build-standalone shipping arm64 Windows Python builds and lets us manage the transition in some better way like a configuration knob.
Member
|
I don't think this is quite right, won't we ignore any arm64 Python installations on the machine now? I'll look more closely later. |
Contributor
|
My alternative solution is here: |
kdeldycke
added a commit
to kdeldycke/repomatic
that referenced
this pull request
Jun 8, 2025
Contributor
Author
|
All right, @Gankra has been thinking harder about how to implement this well, so closing this in favor of her changes :) |
Gankra
added a commit
that referenced
this pull request
Jun 30, 2025
and prefer emulated x64 windows in its stead. This is preparatory work for shipping support for uv downloading and installing aarch64 (arm64) windows Pythons. We've [had builds for this platform ready for a while](astral-sh/python-build-standalone#387), but have held back on shipping them due to a fundamental problem: **The Python packaging ecosystem does not have strong support for aarch64 windows**, e.g., not many projects build aarch64 wheels yet. The net effect of this is that, if we handed you an aarch64 python interpreter on windows, you would have to build a lot more sdists, and there's a high chance you will simply fail to build that sdist and be sad. Yes unfortunately, in this case a non-native Python interpreter simply *works better* than the native one... in terms of working at all, today. Of course, if the native interpreter works for your project, it should presumably have better performance and platform compatibility. We do not want to stand in the way of progress, as ideally this situation is a temporary state of affairs as the ecosystem grows to support aarch64 windows. To enable progress, on aarch64 Windows builds of uv: * We will still use a native python interpreter, e.g., if it's at the front of your `PATH` or the only installed version. * If we are choosing between equally good interpreters that differ in architecture, x64 will be preferred. * If the aarch64 version is newer, we will prefer the aarch64 one. * We will emit a diagnostic on installation, and show the python request to pass to uv to force aarch64 windows to be used. * Will be shipping [aarch64 Windows Python downloads](astral-sh/python-build-standalone#387) * Will probably add some kind of global override setting/env-var to disable this behaviour. * Will be shipping this behaviour in [astral-sh/setup-uv](https://github.com/astral-sh/setup-uv) We're coordinating with Microsoft, GitHub (for the `setup-python` action), and the CPython team (for the `python.org` installers), to ensure we're aligned on this default and the timing of toggling to prefer native distributions in the future. See discussion in - #12906 --- This is an alternative to * #13719 which uses sorting rather than filtering, as discussed in * #13721
kdeldycke
added a commit
to kdeldycke/repomatic
that referenced
this pull request
Jul 7, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See #12906 and astral-sh/python-build-standalone#387 - as soon as we start shipping arm64 Windows Python builds in python-build-standalone, uv is going to start discovering them, and there aren't enough arm64 Windows wheels for that to make sense as a default yet. As a very minimal stopgap, consider those builds incompatible.
No functional change expected at the moment, but this unblocks python-build-standalone shipping arm64 Windows Python builds and lets us manage the transition in some better way like a configuration knob.