No technical reasons. However, CI resources for building that target will be a factor. We tend to focus on the most popular targets for pre-built binaries. It's not clear how widespread musllinux_aarch64 is.

multiarch images are catching up the trend. I think the demand for this will be higher. Can i keep this issue open to see the interest in this?

I've indeed seen more frequent mentions of multi-arch images, and Docker seems to be making a push for those (see, e.g., this intro blog post). It's not yet clear to me if there's any common groups of platform tags being used together that is emerging - maybe through higher-level build tooling. @tuananh what's the set of platforms you are trying to build for?

I've indeed seen more frequent mentions of multi-arch images, and Docker seems to be making a push for those (see, e.g., this intro blog post). It's not yet clear to me if there's any common groups of platform tags being used together that is emerging - maybe through higher-level build tooling. @tuananh what's the set of platforms you are trying to build for?

We have mix-arch cluster at work and building multiarch images by default (amd64 and arm64).

Thanks. And the musl part is a custom choice? Or you're building both with glibc and musl?

Thanks. And the musl part is a custom choice? Or you're building both with glibc and musl?

we use images that use musl (alpine) and some use glibc (wolfi & others) so it would be nice to have both

Just a clearer explanation of the cost:

• maintaining more wheels incurs extra time and effort required by the developers.
• native building of musllinux_aarch64 requires use of Cirrus-CI which comes at a monetary cost to the numpy project. It helps if companies are able to provide sponsorship to offset that cost.

Same here, we normally use Alpine-based containers, but our colleagues on Apple Silicon machines can't build these images because of the missing musllinux wheels. Would be great if they could be added, since the difference in image size can be huge (127 MB on python-alpine vs 204 MB on python-slim).

Thanks @der-eismann, that use case makes sense. I didn't think about this before, but Apple switching to arm64 makes musllinux more relevant if one thinks about "Docker recipe should run the same across Linux, macOS and Windows machines" kind of requirement (and Windows on Arm may add to that).

I will note that on macOS there should be a workaround right now (from this SO question) - slower but should make things work:

export DOCKER_DEFAULT_PLATFORM=linux/amd64

Hey @rgommers, you're right, that workaround does help a bit, but in theory only for building the image. Actually running numpy workloads in an emulated environment is incredibly slow, we're talking about factor 20-100. So I get that it costs money and everything to push this additional wheel, but it would be highly appreciated 🙂

It seems like the case for this is reasonable, and it wouldn't be too hard to do (assuming that there aren't unexpected test failures of course) - WDYT about starting to add these wheels @andyfaff, @charris, @mattip?

Straightforward, I'll get onto it. It'll be on cirrus

These are up on https://anaconda.org/scientific-python-nightly-wheels/numpy/files, so I'll close this issue.

Thanks for adding them @andyfaff, and for the input everyone else.