ENH: Provide Windows 11 ARM64 wheels (#22530)#28836
Conversation
This is mostly adapting and duplicating how the 32-bit no-OpenBLAS
wheels are built, to make ARM64 wheels.
The mamba-org/setup-micromamba github action reports "win_arm64" as
unsupported for installation of anaconda-client at the moment.
Beyond that, a number of tests need to be skipped. They are in
three categories:
- Meson outside of the msdevshell github action does not seems
to be able to find the MSVC linker. (Possibly missing some PATH env)
- No "checks" modules in win-arm64 (yet)
- Mingw GNU objdump does not understand arm64 dll format (yet) to
to generate import libraries.
closes numpy#22530
|
Quite sure that the failed "Linux tests / pypy (pull_request)" test is unrelated - none of this set of changes touches linux builds... |
It is a known bug in PyPy. |
rgommers
left a comment
There was a problem hiding this comment.
Thanks for working on this @HinTak! This looks pretty good, glad to hear that the msdevshell action just works and that almost all tests are passing.
The mamba-org/setup-micromamba github action reports "win_arm64" as unsupported for installation of anaconda-client at the moment.
That is expected; core conda ecosystem tools are currently being bootstrapped, they're not yet available. A little annoying that we have to skip nightly wheel build uploads due to that, since nightly wheels will be useful for the early adopters to test. We can see if we can run an x86-64 version of anaconda-client for the time being.
Mingw GNU objdump does not understand arm64 dll format (yet) to to generate import libraries.
Let's not worry about numpy.distutils, that's too much trouble since it's already deprecated and will be removed completely once we drop Python 3.11 support. Instead of messing with this, let's just not install numpy.distutils at all on win-arm64. All it takes is amending this skip condition:
Line 335 in 94b232f
Could you give that a try?
Meson outside of the msdevshell github action does not seems to be able to find the MSVC linker. (Possibly missing some PATH env)
Could you add the content of a test failure in a comment on this PR? I'll see if I can help resolve this one.
|
Had a look at the CI log. This all looks as expected indeed: SIMD support may not yet be a thing, or detection fails - not urgent right now, but will require follow-up: only the |
|
The mesa stdout message is: The correct path value (earlier from the msdevshell step is): I think there is some sort of vc init Arm windows can run x86_64 binaries, btw. |
|
|
Adding this part resulting in the The ci logs is in my fork (i am just adding the changes there to see if it works first) - I think the detailed log is visible to others? |
This is exactly what the
I can't find a relevant issue upstream. I suspect it's the
It shouldn't affect the sdist generation in CI if you add
Yes they are, I looked at one of your logs before. If you want to point out something specific, you can link to the log directly. |
|
@rgommers I meant that msdevshell's effect does not seem to carry on all the way to the pytest stage - so PATH was correct early on, but got overwritten / undo / reset later just before pytest . I 'll have another go at the distutils and see if I can get around it. |
|
This is the log of an earlier run with the meson related failure - https://github.com/HinTak/numpy/actions/runs/14681173130/job/41204101148 - if you can see anything interesting there? @rgommers |
|
I see the vendor-meson submodule has been updated in main - anybody think that might possibly address the meson msvc issue? |
The conditional failed even worse - I am trying |
|
Changing that conditional on sdist https://github.com/HinTak/numpy/actions/runs/14697380294 means the wheel building fails at a different place. So far the changes here is what "works"... I'd like to see the meson + msvc linker look up at pytest works ( just an idea: is the testing itself overwriting PATH by pretending the git dir to PATH?), but that may take some effort from somebody else more knowledgeable. AFAIK skia-python doesn't use numpy via meson, so this should be useful as is, when merged into a release, for us to put skia-python arm windows support out. |
That is unlikely, it was a minor update.
Thanks. No, the NumPy code looks fine I think, and nothing jumps out. It's probably indeed PATH ordering, just not sure why it's only a problem on the win-arm64 runners. I'll try to find time to have a closer look.
👍🏼 |
|
Modifying the sdist part results in failing like this, for python 3.11 arm windows: I guess the tester can be modified to allow missing import, but IMHO that isn't better than the little skip here. I think there is a chance the skip will work with a later mingw. |
Okay, I won't be able to dig in deeper here, so let's go with the skip for now. This looks about ready. The one thing I'm doubting is whether we should merge the wheel build part, since it's going to be quite slow without OpenBLAS. But perhaps it's still better than nothing - not many people will be able to build with a BLAS library from scratch anyway. So I think I'm okay with merging this and then updating after MacPython/openblas-libs#193 lands to provide |
|
I've put this in. The OpenBLAS builds look to be making progress. |
|
Thanks @HinTak. |
|
Thanks! |
|
When it will be available on PyPi? |
|
With NumPy 2.3.0, probably at the end of June or in July. |
|
@rgommers Let me know if any help is needed to make it sooner than July. NumPy is an essential package and a build dependency for many others. |
|
Thanks for the offer @khmyznikov. There isn't much to do to speed it up though - we have feature releases twice a year. The next one is 2.3.0; the release candidate for it should be up on PyPI much sooner, so downstream projects willing to use a pre-release will be unblocked soon. |
This is mostly adapting and duplicating how the 32-bit no-OpenBLAS wheels are built, to make ARM64 wheels.
The mamba-org/setup-micromamba github action reports "win_arm64" as unsupported for installation of anaconda-client at the moment.
Beyond that, a number of tests need to be skipped. They are in three categories:
- Meson outside of the msdevshell github action does not seems to be able to find the MSVC linker. (Possibly missing some PATH env)
- No "checks" modules in win-arm64 (yet)
- Mingw GNU objdump does not understand arm64 dll format (yet) to to generate import libraries.
closes #22530