uv installs x86_64 Python on arm64 Windows

[burgholzer]

Summary

Just yesterday, GitHub announced that the new Windows 11 ARM runners are now available as public preview.
We tried to switch one of our projects over at munich-quantum-toolkit/core#926, but noticed that our Python testing CI would fail on the new runners.
The corresponding run log can be found here: https://github.com/munich-quantum-toolkit/core/actions/runs/14478587550/job/40610220668?pr=926
It essentially fails because uv is downloading the x86 version of Python, which then lets the package build run smoothly, but fails as soon as the tests get executed because these are the wrong binaries for the host architecture.

A minimum reproducible workflow that shows the failure is

name: UV Reproducer
on:
  push:
    branches:
      - main
  pull_request:
  merge_group:
  workflow_dispatch:

jobs:
  debug-uv:
    name: Debug UV
    runs-on: windows-11-arm
    steps:
      - name: Install the latest version of uv
        uses: astral-sh/setup-uv@v5
      - name: Check the version of uv
        run: uv version
      - name: Instal Python with uv
        run: uv python install 3.9
      - name: Check the Python installations
        run: uv python list

A corresponding run with that can be found here: https://github.com/munich-quantum-toolkit/core/actions/runs/14478932500/job/40611314128?pr=926

There, the uv python install 3.9 results in

Downloading cpython-3.9.22-windows-x86_64-none (21.2MiB)
 Downloaded cpython-3.9.22-windows-x86_64-none
Installed Python 3.9.22 in 2.61s
 + cpython-3.9.22-windows-x86_64-none

I saw over at the python-build-standalone repository that ARM64 builds are in progress (astral-sh/python-build-standalone#387), but not yet ready.

Platform

Windows 11 ARM

Version

uv 0.6.14 (a4cec56 2025-04-09)

Python version

Any

[zanieb]

Thanks for the report!

Does the x86-64 Python run on the ARM machine? Just wondering.

[burgholzer]

Judging from the workflow logs from our repository (specifically, https://github.com/munich-quantum-toolkit/core/actions/runs/14478587550/job/40610220668?pr=926#step:9:1045) I would say so.
pytest seems to start but fails in its collection phase when trying to load some DLL (which, presumably, has the wrong architecture).

[zooba]

Does the x86-64 Python run on the ARM machine? Just wondering.

Yep. Windows ARM64 supports emulation of both x86 and x86-64 executables (and even supports some amount of bridging between them and native DLLs, though that's special magic that Python doesn't use and honestly I've not even fully understood yet). It's just as transparent as the 32-bit emulation on 64-bit OS, including that all DLLs/PYDs need to match the architecture of the executable.

Because most of the Python ecosystem assumes it can only ever run in the native architecture, a lot of libraries will fail if they're running under emulation. We've been trying to enlighten tools and build scripts for the last couple of years, but without actual runners, most projects haven't cared, so they still need updating.

[charliermarsh]

I think there was an issue elsewhere where we discussed whether x86 actually should be the default for ARM Windows machines, since so few packages publish ARM Windows wheels...?

[burgholzer]

I think there was an issue elsewhere where we discussed whether x86 actually should be the default for ARM Windows machines, since so few packages publish ARM Windows wheels...?

I bet that will change over time now that public runners are available. Could be wrong though.

[zooba]

Yeah, I'm also betting that the runners existing will make a difference. And also hesitant to make ARM the default - but that said, ARM should certainly be the default for anyone building their packages on an ARM machine. Maybe they'll be blocked by an upstream dependency, but for the vast majority of users, they are an upstream dependency for someone else.

Making ARM builds the default on python.org means millions of "normal" users (e.g. school kids and such) will get the build. Package developers are a minority in these terms, which is why they need to opt in. I'm not sure where uv fits in here, but I suspect it's a higher ratio of people who should get native ARM builds by default (but probably not high enough).

[geofft]

+1 to the sentiment that we should make arm64 Python available but not yet the default. I think it shouldn't be the default in uv even when astral-sh/python-build-standalone#387 lands, and I think the status quo is that uv itself is arm64 but it picks the x64 binary as the best available option (by the rules in crates/uv-python/src/platform.rs), right? So I think that means that we need to implement some toggle somewhere to make uv reject arm64 Python on arm64 Windows specifically.

I think in particular I would advocate for

• by default, people who do a irm https://astral.sh/uv/install.ps1 | iex on Windows arm64 should have this toggle enabled, so that they get x64 Python (and use the built-in emulation), and probably get a warning/FYI about this either when installing uv or when downloading a Python build, with an explanation what's going on (maybe a link to a tracking issue about switching the default over?)
• there should be a documented way to turn this toggle off and opt into arm64 Python on Windows
• possibly, this toggle should be default off for the astral-sh/setup-uv action, since people who are using GHA on Windows arm64 are presumably doing so on purpose and can easily switch to x64 if that doesn't work for them and don't want emulation (as opposed to e.g. people with an arm64 Windows laptop)
• we give ourselves some defined criteria for Windows arm64 wheel availability (definitely at least numpy, but probably we come up with a set of wheels), and flip the toggle off at that point, but keep the toggle available for users
• ideally but optionally, if we find ourselves trying to build something from source and we notice that there's a Windows x64 wheel, we should print a very visible warning that the user might have a better experience using x64 Python