Skip to content
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

Provide x64, arm64, and universal2 arch selectors for darwin #547

Open
mattip opened this issue Nov 22, 2022 · 9 comments
Open

Provide x64, arm64, and universal2 arch selectors for darwin #547

mattip opened this issue Nov 22, 2022 · 9 comments
Labels
feature request New feature or request to improve the current logic needs eyes

Comments

@mattip
Copy link

mattip commented Nov 22, 2022

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.

@mattip mattip added feature request New feature or request to improve the current logic needs triage labels Nov 22, 2022
@MaksimZhukov
Copy link
Contributor

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.

@jdogmcsteezy
Copy link

jdogmcsteezy commented Nov 28, 2022

@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?

@mattip
Copy link
Author

mattip commented Nov 28, 2022

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.

@jdogmcsteezy
Copy link

@mattip, I should have thought about it a little harder, haha. Thanks for the clarification

@NeilJed
Copy link

NeilJed commented Dec 7, 2022

+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.

@mayeut
Copy link
Contributor

mayeut commented Dec 11, 2022

@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.

@mattip
Copy link
Author

mattip commented Dec 11, 2022

@mayeut: nice.
FWIW, the run you pointed to above seems to use x86_64 for the CPython run. Is that intentional?

@mayeut
Copy link
Contributor

mayeut commented Dec 11, 2022

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).

@alex
Copy link

alex commented Jan 14, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request to improve the current logic needs eyes
Projects
None yet
Development

No branches or pull requests

7 participants