-
-
Notifications
You must be signed in to change notification settings - Fork 182
Add ARM64 Windows builds for Python 3.11+ #387
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
116a612
to
bb7bc6e
Compare
We're failing missing
on amd64, you can see we copy this file
but we don't on arm64
Looks like |
49b6f84
to
00ea84c
Compare
By manually copying the
Where we fail to run the PGO tests because, of course, we're not on an ARM runner. |
I don't really know what the plan is here. There aren't public ARM Windows runners (though they might be eventually actions/runner-images#10820 / github/roadmap#970). We (Astral) could pay for runners, but I can't set that up in this repository. We could skip PGO, but we're still going to fail later (we need to invoke |
Now that this is in the Astral org, I intend to try adding an ARM runner. |
As a note, before releasing this we need to add proper prioritization for these builds to uv — as arm64 wheels are not prevalent we may not want to actually use these builds by default. |
FWIW, we still consider them experimental in upstream, and I'm regularly tracking whether to make them non-experimental. Right now, that's not going to happen anytime soon, unless I get sick of the people who are meant to be using them going "I'm not going to fix my package/tool until it's non-experimental" when it's still experimental because they haven't fixed anything (okay, clearly I'm already sick of them, but I can't shout at them all at once 😆 ) When we think it's time to unleash users on these builds by default, it'll be announced as part of an upstream beta release (or earlier, but probably not earlier - definitely no later than beta). |
Co-authored-by: Adrian Antkowiak <adiantek@gmail.com>
3.9 fails validation due to missing
3.13 fails more eagerly with the same problem
Looks like this is because the artifact we use for tcl/tk does not include arm64 binaries — so we'll try the newer version. |
@@ -499,6 +499,13 @@ def hack_project_files( | |||
python_version, | |||
) | |||
|
|||
# `--include-tcltk` is forced off on arm64, undo that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forgot about this - glad I'm following your PR.
python/cpython#132650 will fix it in 3.13 and 3.14, FYI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Appreciate it!
Okay now this is working on 3.11+, I don't want to get side-tracked debugging the 3.9 / 3.10 tkinter problems. We'll also need to add these builds to the release targets. |
Neither did I, which is why we never enabled it upstream for those versions. Honestly, I wouldn't bother with 3.11 and 3.12 either. There are potentially bugs in those that were never fixed. There's also a known compiler bug in 14.43 (searching build output for |
Hi @zanieb, thank you for your work on this PR! I was wondering if there are any pre-built binaries available for testing the ARM64 Windows build on devices like the Surface Pro 9. If not, would it be okay if I try compiling this branch to test it myself? Thanks in advance! |
@gr3vios If you're just looking to test Python itself, then there are releases on python.org and CI-friendly packages at https://nuget.org/packages/pythonarm64 that are pre-built. All Windows builds are essentially standalone, the installers are mainly there for people who like installers (most users). If you were planning to test uv, then I expect you'll have to wait for the build support here to be completed. |
The artifacts are also available from this branch at https://github.com/astral-sh/python-build-standalone/actions/runs/14574945166?pr=387 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. (I am still of the opinion we shouldn't yet make this the default for uv because of lack of Windows arm64 wheels in the ecosystem, but I agree with the argument in the linked issue that making this available as an option is how we get the ecosystem support to happen.)
# Copy `applink.c` to the include directory. | ||
source_applink = source_root / "ms" / "applink.c" | ||
dest_applink = install_root / "include" / "openssl" / "applink.c" | ||
log("copying %s to %s" % (source_applink, dest_applink)) | ||
shutil.copyfile(source_applink, dest_applink) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain in the comment what this is and why it's needed? (Why didn't we need this before?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can try, but I don't fully understand.
If I understand correctly,
i.e., once this merges, the next time we sync python-build-standalone releases in uv, arm64 Windows users will get an arm64 Python. If so, I think we should hold off on releasing this until we have some way to default uv users to x64 for the time being. (See astral-sh/uv#12906 (comment)). |
Yes, but I can't easily test an implementation of that until these are released. I think it'll be trivial to exclude them if we decide it's too much work to figure out how to adjust the preferences, so I don't really see it as a blocker — just something to be aware of when we release and sync. |
Picking up #93