-
Notifications
You must be signed in to change notification settings - Fork 617
Provide x64, arm64, and universal2 arch selectors for darwin #547
New issue
Have a question about this project? Sign up 8000 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
Comments
Hello @mattip! Thank you for the suggested idea! |
@mattip, this states that runners for arm64 macOS are generally available. I do see the open issue you referenced that says "beta". 528 and 507 seem in conflict to me. @MaksimZhukov, what am I missing here? |
The link you posted states that "self-hosted runners are available". That is great, and is probably enough to justify formalizing the syntax for the selectors now. I was relating to the possibility of github-hosted runners, which seems to be not generally available yet. |
@mattip, I should have thought about it a little harder, haha. Thanks for the clarification |
+1 To this. I'm building an Ubuntu 22.04 runner on ARM64 from the runner-images repo and the lack of ARM64 toolcache packages makes it impossible to use this action. TBH all the "setup/xxx" toolcache packages should be multi-arch. |
@mattip, PyPy already works out of the box on macOS arm64 self-hosted runners (so should be the same on github-hosted runners once available): https://github.com/mayeut/setup-python/actions/runs/3669884297/jobs/6204031022 I'm not sure if universal2 selector should be supported here at all. At least arm64 & x64 shall (so, that's already the case for PyPy). I opened actions/python-versions#214 to get support for CPython, let's see what maintainers say. |
@mayeut: nice. |
Yes, since there's no arm64 package in python-versions, I was just checking if reusing the x86_64 python 3.11 one would work as-is (since it's a universal2 pkg underneath, it works). |
For readability purposes, it'd be great if the action accepted universal2/arm64 selectors -- right now we're doing x64 with a self-hosted arm64 runner and relying on the fact that it happens to fetch a universal2 binary. |
Hello @mattip, Thank you for your feature request! We are happy to inform you that Framework builds are available for Python versions 3.11 and above, for both x64 and arm64 architectures. For these versions, the official macOS universal2 Python binaries are downloaded from python.org, archived, and provided along with the installation script for further distribution and installation. Additionally, Framework builds are available for arm64 packages starting from Python version 3.9 and above. The primary difference for these builds is the adjustment in the tool cache destination. Please feel free to reach out if you have any further questions or encounter any issues! |
Are earlier versions (of Python) and support for installing PyPy on ARM64 still perhaps planned given this is still open? More specifically I'm finding this issue as I seem to get:
when attempting to ask for:
on macOS (despite there of course being ARM64 builds available). |
Hello @Julian, Thank you for your feedback. We appreciate your interest in using PyPy 2.7 with ARM64 architecture. As you mentioned, the PyPy version is available for download and is successfully extracted during the setup process as per the below test run screenshot. However, our current focus is on supporting Python packages, and we do not have immediate plans to include PyPy support. Thank you for your understanding. Please feel free to reach out if you have any further questions. ![]() |
Hello @Julian, Please let us know in case of any concerns/clarifications on the above |
Hey @aparnajyothi-y thanks for following up! I'd seen your response but the screenshot confused me because you got different behavior I did! So either I did something wrong then or something else has changed -- specifically in your screenshot I see PyPy ends up getting downloaded and installed, regardless of the first cache miss, whereas in my build it simply failed completely after that! So I made a note to try this again before responding to check whether there was really anything to ask for -- if indeed it installs for ARM64 even if it's not in the local cache that seems totally reasonable behavior to me. I'll double check but essentially I think you answered my ask! |
Hello @Julian, Thanks for the update! Glad the screenshot helped clarify things used the below code snippet. From what I’ve seen, the current behavior does fall back to installing PyPy after a cache miss, which is expected. Please let us know if your re-run shows anything different!
|
Hello Everyone, Proceeding to close this as this feature is implemented and confirmed. |
I'd like to ask for x64 thin binaries for python: If you want to build or use x64 on any of the aarch64 runners, then you need to: a) use a thin binary for python that ensures it always runs x64 (because aarch64 doesn't exist)... or... So I'd like to request that this be reopened to add thin binaries for python for x86-64. Getting x64 to work on arm runners is going to be difficult without the thin binaries. |
Hello @Julian, thank you for the detailed context. The current issue pertains to Framework builds and their availability for various architectures, including arm64 and x64. Your request for x64 thin binaries on aarch64 runners appears to be a distinct requirement, as it focuses on enabling x64 Python execution without relying on arch -x86_64 prefixes. To help us better track and evaluate this feature, we recommend raising a new issue specifically for x64 thin binary support on ARM runners. This will ensure proper visibility and allow us to assess it independently. Please feel free to open one, and let us know if you'd like help outlining the request. |
Description:
Describe your proposal.
As described in this comment by @misl6, it would be nice to add the possibility to choose between
arch = universal2, arm64, x64
on darwin (macos).Justification:
Justification or a use case for your proposal.
Runners for arm64 macos are in the github roadmap, but are not generally available. Once they are, it would be nice to be able to use either "thin" (x86_64 or arm64) or universal2 pythons on that image. Some work toward this was done in PR #114 which was merged then reverted. The design for the arch selector should already be worked out before making the images available:
Note that PyPy is going to release both thin arm64 and x86_64 binary packages in its next release, and CPython already has a universal2 package.
I would propose supporting all three alternatives, as the scientific python stack (NumPy, SciPy, and more) and conda-forge have decided to support thin binary packaging only. It would be convenient if this action would make it easy to support those decisions by not forcing a universal2-only solution.
xref issue #108 which discusses the need for arm/arm64 python.
Are you willing to submit a PR?
Yes, but I don't know if it is relevant for an outside contribution.
The text was updated successfully, but these errors were encountered: