ENH: Build and distribute manylinux wheels for riscv64

[markdryan]

Proposed new feature or change:

I'm opening this issue to start the discussion on what it would take to get the numpy project to build and distribute riscv64 manylinux images.

Why now?

Until recently, it wasn't really possible for Python projects to build binary riscv64 wheels and to distribute those wheels via PyPI. Manylinux and cibuildwheel did not support riscv64 and PyPI did not allow riscv64 wheels to be uploaded. This all changed during the summer of 2025, when cibuildwheel (3.12), manylinux and warehouse all gained riscv64 support. Encouragingly, some projects (lxml, uv, maturin, and critically ninja) have already started uploading riscv64 wheels to PyPI.

Does numpy work on riscv64?

Yes. RISE has been building and distributing numpy manylinux wheels for riscv64 for over a year. Tested builds of numpy==2.3.4 (and some earlier versions) are available for riscv64 here.

There is also already some CI coverage for riscv64 in the upstream numpy project. The Linux Qemu tests / riscv64 job runs on pull requests.

What needs to be done?

When I started writing this section I expected to be creating a long list of tasks that would need to be completed before building numpy riscv64 wheels, but it turns out that a lot of the work has already been done. As far as I can tell, most build dependencies, e.g., manylinux, cibuildwheel, OpenBLAS, and ninja (wheels are available for riscv64) already support riscv64. This just leaves

• riscv64 wheels for openblas-libs. There's already an open-issue and some in flight patches. openblas-libs builds fine on riscv64 but the build is a bit slow. We're currently investigating how to speed these builds up.

• https://github.com/actions/setup-python does not support riscv64 making it difficult to invoke cibuildwheel through the pypa/cibuildwheel action on native riscv64 runners. This is only an issue if using a native riscv64 runner and can be worked around by invoking cibuildwheel manually. This won't be an issue if the wheels are built using qemu.

• Update numpy's wheel building scripts/github actions to generate riscv64 wheels

I'm sure that I must be missing a whole pile of things here. I'll update this list as more work items become known.

How can RISE help?

RISE is aware of the additional burden of supporting a new architecture, as mentioned here. The RISE project should be able to assist by providing engineering resources, to debug riscv64 specific issues, and potentially native riscv64 runners, if required.

[rgommers]

Thanks for the request @markdryan. I'll cross-link #22318 (comment), which is about a very similar request for ppc64le which is a little further along. There will be commonality in the decision criteria we will use for both requests.

[rgommers]

Let me xref the conda-forge support for RISC-V issue as well: conda-forge/conda-forge.github.io#1744

[rgommers]

I'll note that a proper policy for platform support tiers is in the works: gh-30748. RISC-V is one of the most likely platforms to be promoted to a higher tier in the future I'd think, once things mature.

For now this is anyway still blocked on MacPython/openblas-libs#226. Once there are scipy-openblas64 wheels, the next step would be to add a regular CI job to the test suite with a self-hosted runner, similar to what was done for ppc64le.

[rgommers]

There are scipy-openblas64 wheels now.

No support in setup-python seems like a minor thing. For a regular CI job, we can still use cibuildwheel, or installing Python with uv would work too.