actions
Provide x64, arm64, and universal2 arch selectors for darwin
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:
- what is the exact syntax of the selector
- what will the default be
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.
Hello @mattip! Thank you for the suggested idea! We will consider adding this feature and will let you know as soon as we have any decision.
@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 https://github.com/actions/python-versions/pull/214 to get support for CPython, let's see what maintainers say.
@mayeut: nice. FWIW, the run you pointed to above seems to use x86_64 for the CPython run. Is that intentional?
Is that intentional?
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.
