disfavor aarch64 windows in its own house by Gankra · Pull Request #13724 · astral-sh/uv

Gankra · 2025-05-29T22:17:37Z

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, 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.
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
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

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

uv installs x86_64 Python on arm64 Windows #12906

This is an alternative to

Disallow arm64 Windows Python installs for now #13719

which uses sorting rather than filtering, as discussed in

Only show the first match per platform (and architecture) by default in uv python list #13721

zanieb · 2025-05-29T22:24:15Z

crates/uv-python/src/installation.rs

            // Architectures are sorted in preferred order, with native architectures first
-            .then_with(|| self.arch.cmp(&other.arch).reverse())
+            .then_with(|| {
+                // For the time being, manually sort windows to make aarch64 windows disfavored


Why not implement this in

uv/crates/uv-python/src/platform.rs

Lines 40 to 59 in 546a6d0

impl Ord for Arch {

fn cmp(&self, other: &Self) -> std::cmp::Ordering {

if self.family == other.family {

return self.variant.cmp(&other.variant);

}

let native = Arch::from_env();

// Prefer native architectures

match (self.family == native.family, other.family == native.family) {

(true, true) => unreachable!(),

(true, false) => std::cmp::Ordering::Less,

(false, true) => std::cmp::Ordering::Greater,

(false, false) => {

// Both non-native, fallback to lexicographic order

self.family.to_string().cmp(&other.family.to_string())

}

}

}

}

instead under a Windows cfg? Do we need the self.os check here?

(this just looks a lot like the logic already in Arch::cmp and I think it'd be easier to reason about in a single location)

Yeah it's because of the os check. Not that it's super useful now that I think about it harder, but it feels... wrong... that we would resolve a request for python-3.11-darwin-any to intel on arm64 windows.

Hm... it does feel wrong... but like... not a real use-case today. I worry about this being brittle. I'll ponder this overnight.

It does suggest that long-term we need a dedicated Platform type to encapsulate both the OS and the Arch and implement Ord on that instead?

codspeed-hq · 2025-05-29T22:32:58Z

CodSpeed Walltime Performance Report

Merging #13724 will not alter performance

_{Comparing gankra/deprio-arm64-windows (1777186) with main (d9b76b9)}

Summary

✅ 12 untouched benchmarks

konstin · 2025-05-30T07:21:17Z

When applying this, we should make sure that we signal to the user clearly that we prefer x64_86 over aarch64 and how to revert that, both on automatic installation and on uv python list. (This is different from the Apple case where there was an explicit transition with a big announcement on the transparent emulation and users expected software from Intel Macs to keep working.)

Gankra · 2025-05-30T13:40:14Z

When applying this, we should make sure that we signal to the user clearly that we prefer x64_86 over aarch64 and how to revert that, both on automatic installation and on uv python list

As in uv should print messages whenever it detected it was doing this, or a public marketing campaign?

Gankra · 2025-05-30T13:42:59Z

Also wanna note, we don't really need to land this until we go to update to a PBS that ships arm64 windows builds, so there's no rush to land this. I don't think we have any reports of users installing system intel and arm64 pythons on windows and getting mad uv isn't picking the intel one (but this PR would change that).

konstin · 2025-05-30T15:15:26Z

We should print a note when uv installs a managed Python interpreter that is not native and not explicitly requested as non-native by the user.

Refs: astral-sh/python-build-standalone#387 (comment) astral-sh/uv#12906 astral-sh/uv#13719 astral-sh/uv#13724

Gankra · 2025-06-13T17:51:29Z

Pushed up a fixed impl with the requested diagnostic (zanie wanted a note, not a warning).

crates/uv-python/src/platform.rs

zanieb · 2025-06-13T18:05:10Z

Can we add a test case for this? Like the macOS emulated one? We don't run the test suite on arm Windows though, so that's kind of annoying. Maybe better as a follow-up, though we could at least write a janky integration test with a bash assertion in CI? Like integration test | uv python on arm windows?

Gankra · 2025-06-13T18:08:25Z

Can we add a test case for this? Like the macOS emulated one? We don't run the test suite on arm Windows though, so that's kind of annoying. Maybe better as a follow-up, though we could at least write a janky integration test with a bash assertion in CI? Like integration test | uv python on arm windows?

I was planning to explore testing more when we PR the PBS update that adds windows releases.

zanieb · 2025-06-13T18:10:28Z

That makes sense, though I'd double check we have existing test coverage to ensure this doesn't "break" anything (we do have a couple CI jobs covering aarch64 windows)

Gankra · 2025-06-30T17:43:49Z

Added a "aarch64 on aarch64 windows" smoketest to go with the "x64 on aarch64" one

Refs: astral-sh/python-build-standalone#386 Nuitka/Nuitka#3449 astral-sh/python-build-standalone#387 astral-sh/uv#13719 astral-sh/uv#13724

…#15027) Addresses this outstanding item from a previous review #13724 (comment) I'm interested in this now for consolidating some logic in #12731

This allows `PythonDownloadRequest` which is used for parsing general install key requests to have missing segments, which unblocks requests like `windows-aarch64` or `cpython-linux` (whereas before those would require `any-any-windows-aarch64` and `cpython-any-linux` respectively). We still require strict ordering of segments. Previously, we only allowed missing segments at the end of the key. This uses a state machine for parsing, which is quite a bit more complicated. I'm a little hesitant about the possibility that this regresses error messages and the complexity of the implementation, but `uv run -p aarch64` seems valuable following #13724. The alternative to this would probably be to make these explicit in various places? e.g., expose `--python-arch`, `--python-libc`, and `--python-os`? Or make `--python-platform` (which already exists) accept a subset of the keys? There is a possibility of regressions here, e.g., if something matches this parser it will not fallback to the `PythonRequest::ExecutableName` case and we've made this parser more permissive, but I think that should be quite rare?

Gankra added the internal A refactor or improvement that is not user-facing label May 29, 2025

Gankra mentioned this pull request May 29, 2025

Disallow arm64 Windows Python installs for now #13719

Closed

zanieb reviewed May 29, 2025

View reviewed changes

zanieb self-assigned this May 30, 2025

kdeldycke added a commit to kdeldycke/repomatic that referenced this pull request Jun 8, 2025

Force uv to ignore managed Python on Windows ARM 64

ef6263f

Refs: astral-sh/python-build-standalone#387 (comment) astral-sh/uv#12906 astral-sh/uv#13719 astral-sh/uv#13724

Gankra force-pushed the gankra/deprio-arm64-windows branch from 311814a to bc0dac8 Compare June 13, 2025 17:47

zanieb reviewed Jun 13, 2025

View reviewed changes

crates/uv-python/src/platform.rs Outdated Show resolved Hide resolved

zanieb approved these changes Jun 13, 2025

View reviewed changes

zanieb mentioned this pull request Jun 14, 2025

uv installs x86_64 Python on arm64 Windows #12906

Open

Gankra temporarily deployed to uv-test-registries June 30, 2025 17:31 — with GitHub Actions Inactive

Gankra temporarily deployed to uv-test-publish June 30, 2025 17:32 — with GitHub Actions Inactive

Gankra added 3 commits June 30, 2025 15:31

disfavor aarch64 windows in its own house

e30b760

fixup

4f419a4

add native aarch64 windows smoketest

eb2eddf

Gankra force-pushed the gankra/deprio-arm64-windows branch from 4ea8c94 to eb2eddf Compare June 30, 2025 19:31

Gankra temporarily deployed to uv-test-registries June 30, 2025 19:33 — with GitHub Actions Inactive

Gankra temporarily deployed to uv-test-publish June 30, 2025 19:33 — with GitHub Actions Inactive

Gankra merged commit 317ce6e into main Jun 30, 2025
87 of 88 checks passed

Gankra deleted the gankra/deprio-arm64-windows branch June 30, 2025 21:42

zanieb mentioned this pull request Jul 2, 2025

Allow Python requests with missing segments #14399

Merged

kdeldycke mentioned this pull request Jul 7, 2025

Why does nuitka reports x86_64 architecture on windows-11-arm runner? Nuitka/Nuitka#3449

Closed

zanieb mentioned this pull request Aug 2, 2025

Refactor os, arch, and libc information into a shared Platform type #15027

Merged

ofek mentioned this pull request Nov 27, 2025

Fix profiling tests on Windows ARM64 jcrist/msgspec#959

Merged

	impl Ord for Arch {
	fn cmp(&self, other: &Self) -> std::cmp::Ordering {
	if self.family == other.family {
	return self.variant.cmp(&other.variant);
	}

	let native = Arch::from_env();

	// Prefer native architectures
	match (self.family == native.family, other.family == native.family) {
	(true, true) => unreachable!(),
	(true, false) => std::cmp::Ordering::Less,
	(false, true) => std::cmp::Ordering::Greater,
	(false, false) => {
	// Both non-native, fallback to lexicographic order
	self.family.to_string().cmp(&other.family.to_string())
	}
	}
	}
	}

Comments

Conversation

Gankra commented May 29, 2025 • edited by zanieb Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zanieb May 29, 2025

Choose a reason for hiding this comment

Uh oh!

zanieb May 29, 2025

Choose a reason for hiding this comment

Uh oh!

Gankra May 29, 2025

Choose a reason for hiding this comment

Uh oh!

zanieb May 29, 2025

Choose a reason for hiding this comment

Uh oh!

codspeed-hq bot commented May 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

CodSpeed Walltime Performance Report

Merging #13724 will not alter performance

Summary

Uh oh!

konstin commented May 30, 2025

Uh oh!

Gankra commented May 30, 2025

Uh oh!

Gankra commented May 30, 2025

Uh oh!

konstin commented May 30, 2025

Uh oh!

Gankra commented Jun 13, 2025

Uh oh!

Uh oh!

zanieb commented Jun 13, 2025

Uh oh!

Gankra commented Jun 13, 2025

Uh oh!

zanieb commented Jun 13, 2025

Uh oh!

Gankra commented Jun 30, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Gankra commented May 29, 2025 •

edited by zanieb

Loading

codspeed-hq bot commented May 29, 2025 •

edited

Loading