Repository navigation
ENH: Build and distribute manylinux wheels for riscv64 #30216
Description
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.
Activity
rgommers commentedon Nov 14, 2025
Thanks for the request @markdryan. I'll cross-link #22318 (comment), which is about a very similar request for
ppc64lewhich is a little further along. There will be commonality in the decision criteria we will use for both requests.rgommers commentedon Nov 16, 2025
Let me xref the conda-forge support for RISC-V issue as well: conda-forge/conda-forge.github.io#1744
ci: add riscv64 manylinux wheels
ci: add riscv64 manylinux wheels
ci: add riscv64 manylinux wheels (#527)
rgommers commentedon Jan 31, 2026
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-openblas64wheels, 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 forppc64le.rgommers commentedon Feb 1, 2026
There are
scipy-openblas64wheels now.No support in
setup-pythonseems like a minor thing. For a regular CI job, we can still usecibuildwheel, or installing Python withuvwould work too.ci: add riscv64 to the wheel build matrix
gounthar commentedon Mar 12, 2026
Thanks @rgommers for laying out the roadmap — self-hosted runner CI makes a lot of sense for riscv64.
A couple of resources that could help with the CI runner step:
We have two BananaPi F3 boards (SpacemiT K1, 8 cores @ 1.6 GHz, 16 GB RAM, rv64imafdcv with full RVV 1.0) already running as GitHub Actions self-hosted runners for riscv64 wheel builds across ~28 projects. We could register one for numpy CI if that's useful as a starting point.
The Cloud-V initiative provides cloud-based RISC-V CI infrastructure — hosted RISC-V runners that could offer better availability and reliability than individual boards, which would be important for a project of numpy's scale.
I've also opened PR #30995 with a minimal QEMU-based approach (just adds
manylinux_riscv64to the existing wheel matrix), though I understand you may prefer the self-hosted runner path for both CI testing and wheel building.For reference, we've been building and distributing tested numpy riscv64 wheels through a community PEP 503 index at https://gounthar.github.io/riscv64-python-wheels/simple/numpy/ — happy to share any build notes or test results that would help move this forward.
rgommers commentedon Mar 12, 2026
This doesn't seem to exist, and the link is broken. What is going on there?
gounthar commentedon Mar 12, 2026
Apologies for the broken link; the correct URL is Cloud-V, run by 10xEngineers and funded by RISC-V International through the RISE project. They provide free CI/CD infrastructure for open-source RISC-V projects.
Another option that's appeared recently: riscvrunners.com: a self-service RISC-V CI SaaS with a free emulated tier (3,000 min/month) and paid native hardware tiers.
Sorry for the confusion with the URL.
rgommers commentedon Mar 13, 2026
Thanks @gounthar, that all looks good. It's not super mature yet it looks like, but I think we can try. Emulation will be too slow, and I don't really want to jump to paid native runners at $0.15/min, so I think this is the best option:
One thing I'm missing from those docs is info on caching. It'd be useful if it stated that it's not supported, or it works with
actions/cache, or some other option. Depending on build speed, that could be useful perhaps.gounthar commentedon Mar 13, 2026
Good question about caching. From our experience running riscv64 CI on two BananaPi F3 boards with
github-act-runner:actions/cache: It works: it uses GitHub's cache API over HTTP, so there's no architecture dependency. We useactions/upload-artifact@v4andactions/download-artifact@v4successfully on our riscv64 runners as well. The only caveat is that the cache key should include the architecture (e.g.riscv64in the key) to avoid cross-arch cache hits if you also run x86 jobs.Cloud-V docs gap: You're right that their docs don't mention caching explicitly. I'd suggest reaching out to them at [email protected] or their Discord to confirm, but given that
actions/cacheis just HTTP calls to GitHub's API, it should work on any self-hosted runner regardless of architecture.Build speed context: On our F3 boards (SpacemiT K1, 8 cores @ 1.6 GHz, 16 GB RAM), building NumPy from source takes roughly 5–8 minutes. The Milk-V Pioneer Box (64-core SG2042 @ 2.0 GHz, up to 128 GB RAM) available through Cloud-V would be significantly faster. Caching compiled wheels/build artifacts would definitely help for iterative CI runs.
One practical note: Cloud-V limits you to 1 concurrent job per board type per repository, so if you have a matrix build you'll want to keep it focused. Happy to help test if you'd like a quick smoke test on our hardware before committing to Cloud-V.
1 remaining item
luhenry commentedon Mar 18, 2026
I’ve added a website to document how to install the RISE RISC-V Runners and how it works: https://riseproject-dev.github.io/riscv-runner/
@rgommers would you be happy to give it a try? I can put together a PoC of what that integration would mean in a fork, and submit a PR once it’s going, what do you think?
rgommers commentedon Mar 19, 2026
Nice, thanks @luhenry. That looks like a good idea. I had a browse through the docs, and it answered my main questions so far. I think we can try to install this GitHub App indeed. I'll report back once I've tried that.
rgommers commentedon Mar 19, 2026
This seems a bit outdated by the way: https://riseproject.gitlab.io/python/wheel_builder/maintain.html#building-new-versions-of-numpy-and-scipy. There are
riscv64wheels up on PyPI now: https://pypi.org/project/scipy-openblas32. And the pins for selecting the version at https://github.com/numpy/numpy/blob/main/requirements/ci_requirements.txt should be up-to-date for our wheel build machinery, so no more git archeology needed hopefully.rgommers commentedon Mar 19, 2026
I believe at the moment we only have limited support for RVV, and as with all SIMD support it's optional so if it's missing from the build machine then that's not a problem. If you have a mix of machine types, I think that should be fine. As far as I understand, RVA23 just makes a set of RVV instructions mandatory, right? If so, I think we don't have very specific requirements here.
rgommers commentedon Mar 19, 2026
I reviewed the GitHub App in more detail and am happy with its provenance and permissions it wants. It seems to be in very heavy development though, almost all code is from the past 2 weeks with O(10) commits today and yesterday. I'd normally be inclined to wait a little bit until the dust settles. @luhenry if it helps you to install it right now I can though - let me know what you think.
luhenry commentedon Mar 19, 2026
@rgommers It's indeed in heavy development but it's reaching a state where I don't expect large changes anymore. There are all the most basic features, and it's high time to get it used out there. Also, to help stability, there are two branches: a staging and prod branch. The staging is used exclusively by the
riseproject-devorg and some very specific ones, to be the canary in the coal mine. Numpy and any other org like this would be in "prod" and so wouldn't be impacted by the latest changes until they have proven to work on staging already.Happy to be on quick dial (via whatsapp for example) to help with initial bring up, and I would of course monitor it closely to make sure everything works as expected.
andyfaff commentedon May 4, 2026
@rgommers, have we finalised on a decision to move this to a tier 2 or 3?
rgommers commentedon May 12, 2026
Not finalized yet, but we should. My proposal: let's get regular CI support merged and see for a while if it's stable (i.e., move it to Tier 3 now), and once it's run stably for at least a month, we can discuss whether we'd want to move it to Tier 2. Does that sound reasonable?
If so, we can add it to the table in https://numpy.org/neps/nep-0057-numpy-platform-support.html#tier-3 once gh-30995 is merged.
rgommers commentedon May 12, 2026
It does require a mailing list post, I can draft a quick one after lunch pointing back at this issue.
andyfaff commentedon May 12, 2026
That seems reasonable to me.
rgommers commentedon May 12, 2026
Much appreciated @luhenry.
@gounthar would you want to be listed on the RISC-V entry at https://numpy.org/neps/nep-0057-numpy-platform-support.html#tier-3 as well when we add that?
rgommers commentedon May 12, 2026
Mailing list message about promotion to Tier 3: https://mail.python.org/archives/list/[email protected]/thread/EYRL2GRK7JT73ULUGK2KN7DETMDYG4HN/
gounthar commentedon May 12, 2026
Yes, happy to be listed. One caveat: I'm a volunteer contributor, no dedicated time for numpy riscv64. I'll help with CI and build issues and keep an eye on things, but I probably shouldn't be the primary contact if that implies regular availability. "Community contact" or "willing to help" framing fits better, but I'll defer to whatever works for the NEP structure.
rgommers commentedon May 12, 2026
Thanks @gounthar, much appreciated. And yes, we understand volunteer constraints perfectly well - we have a lot of volunteers maintainers. And for the ones with day job bandwidth, that's typically only for specific topics (and CI maintenance tends to not be on the list). It's all best effort.
rgommers commentedon May 12, 2026
I just saw https://riseproject.dev/2026/05/12/rise-risc-v-runners-six-weeks-in/, nice summary of the CI infra support status.