Add support to AArch64 wheel #93
Conversation
odidev
force-pushed
the
scipy-wheel-support-aarch64
branch
from
1264884 to
e446ac4
Compare
.travis.yml
Outdated
| @@ -28,6 +28,24 @@ jobs: | |||
| # Exclude the default Python 3.5 build | |||
| - python: 3.5 | |||
| include: | |||
| - stage: Build and test wheel | |||
| os: linux | |||
| arch: arm64 | |||
There was a problem hiding this comment.
Stages run sequentially and if any of the stage is failing, the remaining stages will not run.
There was a problem hiding this comment.
I can see the scipy-wheel builds are running on travis-ci.org and arm64-graviton2 is available only on travis-ci.com. Please have a look at the discussion here. Using arm64-graviton2 will require scipy-wheel builds to migrate on travis-ci.com. Also, the method/configuration to use arm64-graviton2 is not officially declared.
There was a problem hiding this comment.
Travis.com offers free usage to public/OSS repositories, and the migration should be simple as long as this project does not have any weird dependencies. Its highly recommended to move sooner rather than later as .com is the only platform that will offer arm64 builds on graviton2 instances.
|
close/reopen to pull in latest master after scipy/scipy#12765 |
config.sh
Outdated
| local testmode="full" | ||
| else | ||
| local testmode="fast" | ||
| fi | ||
| # Check bundled license file | ||
| python ../check_installed_package.py | ||
| # Run tests | ||
| python ../run_scipy_tests.py $testmode -- -n2 -rfEX | ||
| python ../run_scipy_tests.py $testmode -- -n8 -rfEX |
There was a problem hiding this comment.
I tried restarting the single travis CI matrix entry failure which is this:
worker 'gw5' crashed while running 'signal/tests/test_signaltools.py::TestConvolve2d::test_large_array'
This makes me wonder if this -n8 multi-core test setting is being applied to all jobs and not just the ARM64 job? If so, we'd probably want to revert that--I think regular Travis for x86_64 tends to provide ~2 cores? Maybe that's part of the reason for that strange crash?
There was a problem hiding this comment.
To clarify, can we just bump up the number of cores used for ARM only?
There was a problem hiding this comment.
Now bumping up the number of cores used for ARM only.
odidev
force-pushed
the
scipy-wheel-support-aarch64
branch
from
e446ac4 to
bf330d6
Compare
odidev
force-pushed
the
scipy-wheel-support-aarch64
branch
from
bf330d6 to
bb7e3e9
Compare
|
PR is hitting issue: "No output has been received in the last 10m0s" however it was passing before. I think it's better to migrate on travis-ci.com to use arm64-graviton2 to speedup Arm64 build/test. |
|
@odidev @tylerjereddy The build and test with arm64-graviton2 log: https://travis-ci.com/github/janaknat/scipy-wheels/builds/181513477 . Takes around 35 min for build+test. But this is with '-n 8' for the tests. |
|
I restarted the job that timed out; not sure on the travis-ci.com migration yet |
|
This PR is blocked with build/test timeout and only the migration on the travis-ci.com can resolve this blocker. May I know the plan for migration to the travis-ci.com? |
|
IIRC bumping to the new travis website might involve the entire organization ("MacPython"). I don't have a sense for how hard that would be to coordinate or how disruptive it might be. cc @mattip @charris @rgommers @matthew-brett |
|
🤷 Can we start a new org, add all the admins, and migrate projects one at a time? |
|
Hi @tylerjereddy , would there be issues migrating repos one at a time (increased limits, special settings)? I know that the PSF, PyCA, and PyPA had some interesting settings in Travis-ci.org, but with some help from Travis they made the migration in a couple hours and everything is working smoothly: See pyca/cryptography#5292 At least from the Travis-ci documentation, migrating a single repo looks rather painless: https://docs.travis-ci.com/user/migrate/open-source-repository-migration |
|
@geoffreyblake If we did decide to do that, would I have sufficient permissions to initiate it as a "collaborator?" |
|
@tylerjereddy , I am not sure. I would suspect you need to have higher privileges to connect Travis-CI.com to the repository. We need the attention of someone with such privileges to chime in here. To get the attention of Travis folks, for help, you can reach out to #embassy channel on Slack. @mustafa-travisci and @michal-at-travisci are two github users that can definitely help with explaining who needs to help with the migration. |
|
I tried signing up for travis-ci.com, but it wants read-write access to all my repos, public and private. Not gonna do that, sorry. So I would like to add my "robot" multibuilder user (that I created to build docker wheels for multibuild) to the MacPython org, and link all their (multibuilder's) repos instead. Does that seem reasonable? Ping @matthew-brett to weigh in on alternatives. |
|
I could start by just adding multibuilder to this repo |
|
Yeah, if Matthew Brett or Ralf or someone else has an opinion that might be helpful. I'm perhaps a little nervous about changes to the wheels repo just because it can drain a lot of time to move things around, and sometimes we don't really realize the full extent of issues until it becomes release crunch time. |
Looks like this doesn't help much; you have your own personal bot, but how do the rest of us log in to travis-ci.com? I just tried and it indeed wants write access to everything, including code (unlike what the TravisCI docs say). |
|
As far as I can tell, anyone can see the build jobs, like here, but only the travis ci owner can restart a build or a job. I don't think travis.com has an "organization" concept. I think that is also true for the current travis.org situation as well? |
|
In an effort to help, I pinged a contact I have at Travis-CI and was sent this PR to their own documentation: travis-ci/docs-travis-ci-com#2886 Hopefully this aids in clarifying some how to do the migration? |
|
Travis-CI Graviton2 General Availability blog post: https://blog.travis-ci.com/2020-09-11-arm-on-aws |
|
@geoffreyblake @janaknat do you have a solution to the problem of logging in to travis-ci.com without giving read-write permissions to all your github repos? Until there is a way to restart builds without giving such wide permissions, it will be hard to recommend travis-ci.com as a viable CI platform. |
|
Not sure if the |
|
OK, thanks @tylerjereddy. It was more of a question of "should I" rather than "can I", but I guess you approve of the approach. I will migrate the build to travis-ci.com under the multibuilder user. |
|
For some reason https://travis-ci.com/dashboard is not showing this repo for the multibuilder user, even though I made that user a "maintainer" of this repo. I opened a support ticket with travis-ci.com and am waiting for a reply. |
|
Thanks Matti, I imagine a few things will break but sounds like we need to do it eventually anyway. |
|
The answer is that travis-ci.com requires the organization not the repo, so the user must have some status in the organization (hopefully less than admin), and they pointed me to this guide for migrating https://docs.travis-ci.com/user/migrate/open-source-repository-migration#the-migration-steps. I just am putting it up here, I haven't read it yet. I have enough permissions to do what needs to be done, I will try to work through this over the next while. |
|
The integration should be live. Close/reopen, let's see if it triggers |
|
Can anyone else see the pipeline running on travis-ci.com https://travis-ci.com/github/MacPython/scipy-wheels/builds/186521682? As @mattip I can see it with no control options, as @multibuilder I can cancel/trigger builds, set up cron jobs, add secrets, ... |
|
@mattip I can see the pipeline running on travis-ci.com |
|
I can see it, and after logging into travis-ci, I can see the controls. |
Same here--looks like I can do restarts and add secret variables, which are probably the main things. |
|
@odidev tests are running on travis-ci.com but stalling on ARM64. Did you really want to test with 8 parallel threads? |
|
I think they were hoping to switch to the new graviton hardware on travis-ci.com, unless that happens without even making a yml change |
|
@tylerjereddy I can post a PR with the Graviton yml change. |
|
@janaknat you could either comment here what needs to change or make a PR against https://github.com/odidev/scipy-wheels/tree/scipy-wheel-support-aarch64 (the source branch of this PR) |
Add config to build wheels using Graviton2
|
whoohoo, it's green |
|
This is awesome, thanks everyone! I just read the thread and the Graviton2 blog post, all looks like really good news. I haven't followed all the technical details over the past two weeks here, so if anyone else (@tylerjereddy ?) who paid better attention wants to hit the green button now, please do! |
|
Yeah, looks good, merging, thanks all! Once there's a "prototype" ARM wheel available from the anaconda upload site it should empower more downstream projects to test with ARM64 workflows in their CI (no time lost building NumPy/SciPy from source in |
|
@tylerjereddy Is there a timeline for when the aarch64 wheels will be available from PyPI? |
|
@janaknat Technically our next major release is ~December; I believe the consensus was not to try backporting the new wheel arch for 1.5.x series (there's a thread in the main SciPy repo about this) because it can cause strange issues in some toolchains when the full complement of support wheel archs changes.. Note that the wheel is currently only building for one version of Python, so we'll likely need to expand that to 3.7, 3.8, and 3.9 (when stable release) for it to be part of the release. In the interim, I've already started using the temporary wheel artifact produced by the work in dowstream ARM64 CI like here: MDAnalysis/mdanalysis#2956 |
|
@tylerjereddy I can add the changes for the other python versions. Is there way to have the aarch64 wheels released sooner? A number of other packages depend on scipy. |
|
One thing CFFI discovered is that PyPI and pip accepts a version number in a Edit: PEP 427 calls it a build tag |
|
@tylerjereddy Any suggestions? |
|
@janaknat I think it will take some convincing that we really don't have an issue to worry about--see this discussion: scipy/scipy#11170 (comment) |
|
Also, keep in mind it generates a fair bit of work for me since the backport of all the ARM64 shims is pretty much guaranteed to run into some problems on the older feature branch (in both the main AND the wheels repo feature branches). |
fixes #11170
Added job to build AArch64 wheel