fix(install): pin an x64 CPython on Windows on ARM

[fernandoviton]

Problem

Installing on a Windows ARM64 machine fails at the dependencies stage, on every one of the four fallback tiers. The installer then misreports the cause:

Using CPython 3.11.9 interpreter at: ...\Python311-arm64\python.exe
Python reports platform: win-arm64
Computed rustc target triple: aarch64-pc-windows-msvc
x Failed to build `cryptography==46.0.7`
`-> Call to `maturin.build_wheel` failed (exit code: 1)
error: could not remove 'rustup-bin' file: Access is denied. (os error 5)
...
This is NOT a version problem -- look for a network/proxy block

It is not a network problem. uv python find 3.11 matches a pre-existing arm64 interpreter, and PyPI publishes no win_arm64 wheel for two exact-pinned deps (cryptography, pywinpty). uv falls back to the sdist, whose build backend is maturin, which wants a full Rust toolchain and an OpenSSL dev environment. Confirmed against the PyPI JSON API: neither cryptography==46.0.7 nor pywinpty==2.0.15 ships a win_arm64 wheel.

The installer only ever validated an interpreter's version, never its architecture.

Fix

Two parts, because there were two independent blocks.

1. Ask uv for an x64 interpreter on arm64. New Get-UvPythonRequest returns uv's fully-qualified request cpython-<ver>-windows-x86_64 on arm64, and the bare version elsewhere. Wired through all 7 uv interpreter call sites (Resolve-AvailablePythonVersion, Test-Python's find/install/verify/fallback, uv venv, both -NoVenv lookups) plus the user-facing recovery string.

The full request syntax is load-bearing: it makes uv skip an already-installed arm64 interpreter rather than match it, so uv python install actually fetches an x64 build. The fallback versions are covered too — falling back to 3.12 on arm64 would reintroduce the identical failure.

2. Make Assert-Arm64WheelSupport test the interpreter, not the CPU. The guard from b28d9f8 diagnosed this exact root cause correctly, but gated on Get-WindowsArch, so it threw on any ARM64 machine — which made its own prescribed remedy ("install the x64 build of Python 3.11 and re-run this installer") unreachable. With part 1 in place the installer provisions precisely that x64 interpreter, and the guard rejected it.

What actually decides wheel resolution is the interpreter's platform tag. Windows on ARM runs x64 under emulation; an x64 CPython reports win-amd64 and resolves every existing amd64 wheel. New Get-PythonPlatformTag probes sysconfig.get_platform() — the same string maturin echoed as Python reports platform: — on the interpreter the tiers will really install into. A win-arm64 tag still fails fast with the same diagnosis and CVE rationale; an unprobeable interpreter fails closed, since failing open would restore the silent fallthrough into the Rust build for exactly the environments least able to diagnose it.

Get-WindowsArch is kept as the cheap pre-filter, so non-arm64 hosts pay nothing and the Prism emulation edge case (an x64 PowerShell host reporting X64 on an ARM64 machine) is still handled.

No behavior change on x64/x86 hosts: the request passes through untouched and the guard returns immediately.

Verification

CI cannot verify this. Every job in tests.yml is ubuntu-latest; there is no Windows or ARM64 runner. So this was verified end-to-end on real Snapdragon-class ARM64 hardware.

To get a truthful test, the x64 Python 3.11 that had been installed manually was uninstalled first and the baseline bug reproduced (uv python find 3.11 → arm64 interpreter). Then, with no manual setup:

Stage	Result
-Stage python	Rejected the arm64 interpreter, installed uv-managed x64 3.11.15
-Stage venv	Using CPython 3.11.15
-Stage dependencies	Passed in 49s — previously failed all four tiers

Resulting venv:

3.11.15 (main, Jul 18 2026) [MSC v.1944 64 bit (AMD64)]
platform tag: win-amd64
machine: AMD64
cryptography 46.0.7   <- the package that could not build
pywinpty OK           <- the other one

Both previously-unbuildable packages installed from prebuilt wheels. No Rust, no OpenSSL, no manual Python install.

Tests

tests/test_install_ps1_arm64_python_arch.py — 15 tests, all of which execute the real PowerShell functions under pwsh rather than pattern-matching the source, per the AGENTS.md ban on reading source in tests. (pwsh ships on GitHub's Ubuntu images; the module skips cleanly if absent.) Get-PythonPlatformTag is asserted against the live interpreter running the test, so it stays correct on any runner arch.

Red-first verified: with scripts/install.ps1 stashed, the interpreter-selection tests and the key regression test_x64_interpreter_on_an_arm64_machine_is_allowed all fail.

Full local run of all 12 install.ps1 test files: 62 passed, 1 skipped. The existing test_install_ps1_windows_arm64.py is unmodified and still green — the rewrite deliberately preserves everything it asserts (function name, Get-WindowsArch in the body, the Windows on ARM text, wheel, and x64|amd64).

One unrelated pre-existing change: two regexes in test_install_ps1_native_stderr_eap.py hard-coded --python $PythonVersion and so were change-detectors on the literal argument spelling; loosened to --python [^}\n]+, which still pins the contract they exist to protect (the flag is passed inside the EAP-guarded block).

Notes

• Test-Python's last-resort "system python" fallback is still not arch-checked. Left alone to keep this narrow — the venv is created via the arch-qualified request, so it is not load-bearing on the failing path.
• Native ARM64 wheel support remains the known gap; this makes the documented x64 path work automatically instead of requiring a manual install that the guard then rejected.

[github-actions]

૮ >ﻌ< ა ci review

_{ran on 2403a69}

all good!