-
-
Notifications
You must be signed in to change notification settings - Fork 636
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
Add support to release aarch64 (arm64) wheels #12183
Comments
We would be interested! The last time we looked at this was before migrating to Github Actions... now that we've done that, there is less cruft standing in the way. Releases are built as a two step process where:
Our Github actions config is generated: pants/.github/workflows/test.yaml Lines 1 to 3 in 3adc0e0
Assistance in updating either of those steps would be very appreciated. |
That'd be great! For distributing as an sdist, I wonder if we want to use maturin, which is the "modern" way to package PyO3 and Rust-CPython applications - it supersedes rust-setuptools. https://github.com/PyO3/maturin. But the tricky thing is we use Pants to handle packaging, and we'd need to have a plugin for maturin, which is doable but also non-trivial. The simpler implementation might be to distribute prebuilt wheels. Specifically, you could use the Manylinux docker image like we currently do for x86:
You could add a new job This also needs to be updated, how we rename the wheels to be manylinux. Note that we really should be using pants/build-support/bin/release_helper.py Lines 709 to 716 in 3adc0e0
Update this to be 9: And this to have the appropriate platform: pants/build-support/bin/release_helper.py Line 564 in 3adc0e0
Although @stuhood prebuildling the wheel adds to our CI time even more - thoughts? I suspect that's a |
I am trying to build the aarch64 wheels but while building native engine I’m facing an error. Please check line number 815 of the following logs: https://github.com/odidev/pants/runs/2840525747?check_suite_focus=true Could you please have a look at the error and share your suggestions for the same? |
Hm... that is surprising! If that error isn't a false positive, it could be that the virtual machines that Github Actions use for If so, you might try lowering the |
Some related work towards this: #13249 |
docs told me to comment my +1 for interest in using |
Hey @mathematicalmichael , thanks for commenting! M1s are supported https://blog.pantsbuild.org/how-we-added-apple-silicon-support-to-pants/. Is that working for you? |
Thank you! I have not yet tried it on my m1 but I do all my development in docker, even there. If I were building atop an ubuntu image (think that pulls in aarch64?) using that machine, could pants work in that environment (eventually, without any workarounds)? |
Re: the blog post Have you considered setting up a github actions self-hosted runner on the m1 being used for the deployments? Can kind of get the best of both worlds: abuse github actions on a currently unsupported architecture, take the human out of the loop in place of a server running on their machine listening for jobs. |
Funny you should mention that! Yes, it was discussed recently that we might buy a Mac Mini for that purpose. |
@mathematicalmichael Is this something you have any experience with? |
not on the m1 specifically but I set up the self-hosted runner on an EC2 instance recently and it was pretty easy. I don't have github enterprise except through work so it's not something I can play around with (my m1 is a personal machine). https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners#supported-architectures-and-operating-systems-for-self-hosted-runners implies this combo seem currently unsupported though. but it does say arm64 has linux support so I would guess an arm-native docker container on m1 will work? |
We are also planning on expanding to graviton in the near future and would appreciate wheels for arm64 Linux as well |
update on my above question: arm-native docker container on m1 will not work as of now I ran Here is a cleaned up dockerfile (can find it printed at bottom of stacktrace too)
stacktrace:
I see wheels published for old versions, so at some point this combination of pants on aarch64 seems to have been supported (or the wheels were just published without annotations that would tell pip otherwise?). I took a look at the files in the error messages and wasn't able to make sense of what changes I might have to make to get it to work. I would very much appreciate help with this as I tend to run my development workflows in docker images and was planning to sandbox |
Thanks, @mathematicalmichael . It looks like our Rust code is failing to run on Linux Arm64 because of this line:
We only define these as valid "platforms": pants/src/rust/engine/process_execution/src/lib.rs Lines 73 to 77 in 8cd274e
So it looks like we indeed do need to do some work on Pants's engine itself to allow you to run on Arm64. Some of the maintainers will be doing planning soon for what we want to contribute in January. Especially with Gravitron + that this is our most upvoted issue now, I'd personally like to try to allocate a few days to unblocking Arm64. |
@Eric-Arellano thank you for pointing me to those lines! I very much appreciate that. Perhaps this is a dumb question but ... if I just added an extra line to that Like, all the rust libs are available, I guess I just don't know exactly how pants works under the hood (I'm only passively familiar with rust) but I would have expected that the |
@mathematicalmichael contributions definitely welcomed! See #12367 for how MacOS ARM64 support was added by @chrisjrn. It will look very similar for Linux ARM64. Check out https://www.pantsbuild.org/docs/contributions-rust for tips on developing in Rust. |
I tried the most straightforward thing I could think of (copy pasted the linux x86 sections) and it's now on the penultimate build step... fingers crossed. If this works... would you want a patch for the 2.8.0 release or something for the main branch? I noticed a difference in line numbers with what you linked above (I'm checked out on the release branch). Thanks for the link! that will help if I encounter an error. (and oh wow that's a lot more changes than I made, guess I wont get my hopes up that this will finish successfully) |
We'd start with the
I suspect it won't be quite as many changes for Linux :) A lot of what that PR was changing is the generic infrastructure for The trickier part fwict is getting CI to run ARM64 and to release pre-built wheels with it. But both those things can be done in followups. The first step is simply letting you build with ARM64 locally. |
if the pants package command is successful, would the wheel exist under here's what I tried so far:
|
I needed to set
I got a wheel in However, when I tried to start a new project with pants, it again tried to find something to download from pypi instead of using what I had installed and failed. How can I tell it "please use this specific wheel on my filesystem"? fwiw, I published it here: |
oh, i see. I needed to be explicit about the pants version matching in |
unfortunately moving beyond basic python starts to hurt... I may be able to package, but running anything proves to be a challenge. is this because of how same thing happened for |
Copying some thoughts here from the Slack thread on this before it gets hidden by the pay-us-to-see-your-history algorithm... The discussion there centered around how to do this in CI. It was decided that a self-hosted GHA runner on a Graviton instance in AWS could do these builds, namely a t4g.medium instance (probably), hosted in the Pantsbuild AWS account. For inspriation or for a source work, https://github.com/machulav/ec2-github-runner was floated as a possible way to use GHA itself to manage the instance lifecycle, and https://github.com/jonico/github-runner-1 was suggested as a way to build a runner AMI in packer. I'm currently working on this. The packer examples repo listed there is pretty complicated—for some reason it wants you to create like 3 different images—but it looks promising. If I can get this to work and create a way to reusably create an image, someone with better creds than I can run the image create on the Pantsbuild org. Then we could work on automating the image creating in a follow-up step. |
@asherf FYI |
I have a basic workflow working on my fork of pants (it is easier for me to work on this kind of feature in a [ork since I have full control there),once things are ready, they will be upstreamed. As you can see in this GHA run: https://github.com/asherf/pants/runs/5576190005?check_suite_focus=true#step:2:6 the @benjyw FYI |
* Make Pants aware of the Linux ARM architecture This is work towards #12183. Having these changes, it was possible to run Pants from sources on a repository on an aarch64 Linux machine (Nvidia Tegra). [ci skip-build-wheels]
It looks like these services have ARM compute available: That last one looks like we might be able to use it to run a GitHub actions runner on arm without the hassle of managing the AWS infrastructure. |
Requested resources here: https://github.com/WorksOnArm/equinix-metal-arm64-cluster/issues/314 |
This gets all tests passing on aarch64: #17645 |
Thanks @benjyw! |
Awesome! Excited to use this |
Problem
On AArch64, ‘pip install pantsbuild-pants’ gives an error. Also no ‘setup.py’ file is available to install/build it through source code. It requires the user to have the development environment installed on his system for building wheels.
Resolution
On aarch64, ‘pip install pantsbuild-pants’ should download the wheels from pypi
@Eric-Arellano, Please let me know your interest in releasing aarch64 wheels. I can help with this.
The text was updated successfully, but these errors were encountered: