Epic: upstream riscv64 wheel support to all 33 packages #15

Activity

1. justeph commented on Mar 19, 2026

   

   justeph

   on Mar 19, 2026

   More actions

   Hi @gounthar , I don't know if you are aware, but the RISE project has already started this kind of work 2 years ago. @threexc and I have been both working with them to assist them on this. Project is called wheel_builder see https://riseproject.gitlab.io/python/wheel_builder/. We currently support around 70 packages. We try to build and tests them by mirroring exactly how upstream does and publish them on our registry.
   I see that some packages are common to your list and our list of packages to upstream :) See https://gitlab.com/riseproject/python/wheel_builder/-/milestones/7#tab-issues. We are already engaged with @threexc in several upstream discussions in several projects. For example I see a conflicting PR on tokenizers: @threexc already opened one last month see huggingface/tokenizers#1963 vs huggingface/tokenizers#1951. I bet there might be others. Would you be interested to share work force on this?

   For you information, @threexc and I submitted a talk about our work on wheel_builder and our upstream work to help various project on this, for the RISC-V Summit Europe that will take place in Bologna from Monday 8th to Thursday 11th June, 2026. In any case, we will both attend.
2. gounthar commented on Mar 19, 2026

   

   gounthar

   on Mar 19, 2026

   Last edited by gounthar

   OwnerAuthor

   More actions

   @justeph Thanks for reaching out; this is exactly the coordination we need!

   I wasn't aware of the specific upstream PRs from @threexc when I opened mine. I've just checked and found overlaps on:

   • tokenizers: my #1963 vs @threexc's #1951
   • safetensors: my #724 vs @threexc's #708
   • frozenlist: my #745 vs yours #741
   • uvloop: my #733 vs AdrianBunk's #711

   I'll close my duplicates and defer to the existing PRs on those. No point duplicating effort!

   I'm already in contact with Ludovic Henry (@luhenry); we're collaborating on RISE native runners for projects that reject QEMU (pyca ecosystem, numpy). I've also joined the RISE Slack. Happy to coordinate there going forward.

   For reference, here's what I've been focused on that might not overlap with your list:

   • pyca infra (cryptography/bcrypt/pynacl Docker images): feat: add riscv64 Docker images for cryptography ecosystem pyca/infra#749
   • RISE runner CI plumbing: actions/setup-python riscv64 fallback, cibuildwheel workarounds
   • Non-Python: Docker CLI, wit-bindgen, wasm-tools, wkg, Jenkins, aomedia/aom

   Would love to attend the RISC-V Summit Europe talk in Bologna! Let's definitely share workforce: more hands, faster riscv64 ecosystem.
3. justeph commented on Mar 19, 2026

   

   justeph

   on Mar 19, 2026

   More actions

   Interesting, we are also in contact with @luhenry indirectly!

   I also found a conflicting PR for pyyaml (mine #909, yours #926 and one from @ffgan I missed before mine #877). I didn't dig too much yet on all others..

   For reference, here's what I've been focused on that might not overlap with your list:

   pyca infra (cryptography/bcrypt/pynacl Docker images): https://github.com/pyca/infra/pull/749
   RISE runner CI plumbing: actions/setup-python riscv64 fallback, cibuildwheel workarounds
   Non-Python: Docker CLI, wit-bindgen, wasm-tools, wkg, Jenkins, aomedia/aom
   

   • cryptography and pynacl are on our list, but tagged as complex and were not our top priority, so feel free to handle this :)

   • about rise runner: I was testing them few weeks ago, but didn't have time to switch back on it. So I would be happy if you can do this also :). FYI, I engaged discussion about native runners with argon2-cffi-bindings maintainer:
     ci: add riscv64 manylinux/musllinux wheels hynek/argon2-cffi-bindings#105. Looks like he might be interested! Maybe you can reach him out?

   • Non-Python: we currently focus on python only, so feel free to continue on this one :)
4. justeph commented on Mar 19, 2026

   

   justeph

   on Mar 19, 2026

   More actions

   We also have an internal bi-weekly meeting. Next one is scheduled on Monday, 23rd March. Would you be interested to join us? So maybe we can sync together?

   👍React with 👍1Reacted by Ludovic Henry
5. threexc commented on Mar 19, 2026

   

   threexc

   on Mar 19, 2026

   More actions

   I'm also working on video_reader-rs - for now, on my own fork until I figure some changes out.

   It's a replacement for decord, which IIRC is in the dependency chain for pytorch. The upstream project depends on pyav-ffmpeg to build its wheels, which I recently got a PR to add riscv64 support into (but no new release with a riscv64 wheel has been published yet).

   In the meantime, I'm trying to fix up the pipeline so it builds for x86_64 and arm64. That way, once pyav-ffmpeg publishes a riscv64 wheel, we can get video_reader-rs building with it too.
6. gounthar commented on Mar 19, 2026

   

   gounthar

   on Mar 19, 2026

   Last edited by gounthar

   OwnerAuthor

   More actions

   @threexc Thanks for the heads up on video_reader-rs; good to know you're working on the pyav-ffmpeg chain. I'll avoid that area.

   Also just closed our harmony PR googleapis/python-crc32c#104 in favor of your googleapis/python-crc32c#98. Found another overlap; updating the epic to reflect all the deferred PRs.

   🚀React with 🚀3Reacted by Trevor Gamblin, Julien Stephan and E Shattow
7. eshattow commented on May 2, 2026

   

   eshattow

   on May 2, 2026

   Last edited by eshattow

   More actions

   Proposal to promote rust riscv64gc-unknown-musllinux from Tier 2 (no host tools) to Tier 2 (with host tools) is tracked at rust-lang/compiler-team#982 and pending none objections to that proposal then on acceptance I'll send a PR to update the docker-rust repo rust-lang/docker-rust#272 and build images for that. Doing so should unblock a few potential wheels promotions to build and publish for riscv64 when depending on there being official rust docker images for the build.

   wheels (some already mentioned) on my list for readying Home Assistant:

   AlexxIT/go2rtc#2236

   Built pillow==12.2.0
   Building grpcio==1.80.0
   Building grpcio==1.80.0
   Building grpcio==1.80.0
   Built grpcio==1.80.0
   Built orjson==3.11.8
   Built pynacl==1.6.2
   Built cryptography==47.0.0

   Built pycares==5.0.1 saghul/pycares#308
   Built zeroconf==0.148.0 python-zeroconf/python-zeroconf#1665
   Built dbus-fast==4.0.4 Bluetooth-Devices/dbus-fast#619

   Prepared 8 packages in 141m 46s
   Installed 101 packages in 918ms

   grpcio is very noticeably the bulk of build duration
8. gounthar commented on May 2, 2026

   

   gounthar

   on May 2, 2026

   OwnerAuthor

   More actions

   The Rust Tier 2 promotion at compiler-team/issues/982 is the missing piece for most of Tier 2 here. Once that lands and docker-rust ships official riscv64 images, cffi / tiktoken / blake3 / cryptography / pynacl all unblock in one shot. Added a note about it as a dependency in the Tier 2 section above.

   Added pycares, zeroconf, and dbus-fast to a new "Deferred to Community" section so we don't open duplicate PRs.

   141m for grpcio matches what we saw on the F3. The build works, it's just slow. Upstream has grpc/grpc#41591 open and RISE has an internal riscv64 workflow running -- I'll keep watching that rather than opening a parallel PR.

   On go2rtc: PR #2236 looks clean. Happy to run it on a RISE riscv64 runner (ubuntu-24.04-riscv) and post results there if it would help move the review along.
9. eshattow commented on May 2, 2026

   

   eshattow

   on May 2, 2026

   More actions

   @gounthar writes:

   The Rust Tier 2 promotion at compiler-team/issues/982 is the missing piece for most of Tier 2 here. Once that lands and docker-rust ships official riscv64 images, cffi / tiktoken / blake3 / cryptography / pynacl all unblock in one shot. Added a note about it as a dependency in the Tier 2 section above.

   An issue and accompanying pull-request with the changes implementing the proposal will need to be submitted to rust-lang/rust referencing the (when-completed) proposal 982. I welcome and appreciate if you want to get involved with that to submit the implementation issue and pull request ahead of when I would have time to do so myself.

   Added pycares, zeroconf, and dbus-fast to a new "Deferred to Community" section so we don't open duplicate PRs.

   The pycares author approved changes and all checks are passing.

   I do not understand what is needing to be changed in zeroconf and dbus-fast workflows so that external PR contributions can pass the checks. The riscv64 build and publish changes are approved and so it is remaining this unrelated workflow problem. If you are experienced with GitHub Actions and wish to make suggestions improving their workflow I am sure it would be appreciated by the author (workflows are similar and I think the same contributing author is involved for both projects).

   141m for grpcio matches what we saw on the F3. The build works, it's just slow. Upstream has grpc/grpc#41591 open and RISE has an internal riscv64 workflow running -- I'll keep watching that rather than opening a parallel PR.

   On go2rtc: PR #2236 looks clean. Happy to run it on a RISE riscv64 runner (ubuntu-24.04-riscv) and post results there if it would help move the review along.

   Go language supports riscv64 outputs and does everything cross-compiled, and so the addition of riscv64 build output to any CI/CD workflow is not complicated. We wait on the go2rtc author to reply.
10. gounthar commented on May 2, 2026

    

    gounthar

    on May 2, 2026

    OwnerAuthor

    More actions

    On the Rust Tier 2 proposal: I'll follow compiler-team#982. Once it's approved and someone needs to file the implementation issue and PR against rust-lang/rust, I'd be glad to help. It would unblock most of the maturin packages at once.

    For zeroconf (#1666) and dbus-fast (#620): I think I can see what's causing the release job failures, though I'm not 100% sure I have the full picture.

    In zeroconf, the job condition reads:

    if: ${{ github.repository_owner }} == "python-zeroconf"

    The ${{ }} interpolates the value into a string before the comparison runs, so GHA ends up evaluating a non-empty string rather than a boolean. Non-empty strings are truthy, so the condition always passes. The job runs on every PR, then fails because the release environment needs write access that PRs don't have.

    Changing it to:

    if: github.repository_owner == 'python-zeroconf' && github.event_name != 'pull_request'

    should fix that.

    In dbus-fast the release job has no if at all, so the same thing happens. Adding if: github.event_name != 'pull_request' to that job should be enough.

    If bdraco just wants to merge past the failing check, that's probably fine too since the riscv64 changes themselves look correct. But if it's useful, I can send a small PR to each repo to fix the condition.

    👍React with 👍1Reacted by E Shattow
11. eshattow commented on May 3, 2026

    

    eshattow

    on May 3, 2026

    More actions

    Oh and I forgot to mention cython/cython which just now closed WONTFIX cython/cython#7646
12. gounthar commented on May 3, 2026

    

    gounthar

    on May 3, 2026

    OwnerAuthor

    More actions

    Thanks for the heads up on cython/cython#7646. The maintainers' reasoning makes sense: Cython already ships a py3-none-any.whl that works on riscv64, and download counts for riscv64 are still low enough that compiled wheels aren't a priority. For this epic, Cython is a build-time dependency for other packages, so the pure Python wheel is enough for CI builds. I'll leave it off the tracking list.
13. eshattow commented on May 5, 2026

    

    eshattow

    on May 5, 2026

    Last edited by eshattow

    More actions

    multidict riscv64 wheels not found in releases and not published to PyPI for the current version 6.7.1

    aio-libs/multidict — riscv64 in odd-arches qemu matrix since 2025
14. gounthar commented on May 5, 2026

    

    gounthar

    on May 5, 2026

    OwnerAuthor

    More actions

    Good catch. PR #1293 adding riscv64 to the CI merged on 2026-02-06, but v6.7.1 shipped on 2026-01-26, 11 days earlier. No release since. The next multidict release should include riscv64 wheels via QEMU.

    Fixing the epic too: 'since 2025' was wrong (it was February 2026), and v6.7.1 predates the riscv64 CI addition.
15. eshattow commented on May 5, 2026

    

    eshattow

    on May 5, 2026

    More actions

    rust-lang/compiler-tools MCP 982 is accepted and the tracking issue rust-lang/rust#156191 is generated. You may self-assign by responding to that tracking issue with @rustbot claim
16. 1 remaining item

    Load more

17. eshattow commented on May 7, 2026

    

    eshattow

    on May 7, 2026

    More actions

    Have we tried yet to get in contact with @ijl about orjson ? I sent an email first day of this month but I did not see any reply yet. The recent orjson 3.1.1.9 release bumps rust requirement to not being attainable on any stable Alpine Linux release from rust 1.89 to rust 1.95; Alpine Linux 3.23 ships with rust 1.91.1
18. luhenry commented on Jun 29, 2026

    

    luhenry

    on Jun 29, 2026

    More actions

    @gounthar we are tracking the RISE work on GitHub at Python Wheels - riseproject-dev/python-wheels
19. eshattow commented on Jul 2, 2026

    

    eshattow

    on Jul 2, 2026

    More actions

    @gounthar writes:

    Thanks for the heads-up. musl riscv64 with full tooling is a meaningful step for the ecosystem. If RISE runner access would help during implementation (ubuntu-24.04-riscv), happy to assist with CI validation or testing.

    I cleared up some disk storage for the big software build exercise and use the day today making progress on this FYI, I did complete a successful ./x.py dist --target riscv64gc-unknown-linux-musl cross-compile with standard ubuntu:24.04 docker image and x86_64 build host as a proof of concept with gcc 15. Next task is walking this back to the minimum versions and options required. I thought it would be simple copy-and-paste and it is not complicated but for me it is taking some time to make sense of the build system, sorry for that delay I do not intend hold up your progress.
20. gounthar commented on Jul 2, 2026

    

    gounthar

    on Jul 2, 2026

    OwnerAuthor

    More actions

    No apology needed, honestly. This is your MCP and your timeline, and "make sense of the build system first" is the right order to do it in. rustc's dist plumbing is a lot to hold in your head at once.

    The offer stands, and I mean it concretely. Once you have a musl dist tarball, I can run it on native riscv64 hardware (a BananaPi F3, SpaceMiT K1) and on a RISE ubuntu-24.04-riscv runner. That covers the part a cross-build host can't check on its own: whether the toolchain and the testsuite actually behave on real silicon. Sanitizers and the profiler are the ones I'd especially want to exercise there.

    One data point that might save you time on the walk-back. On riscv64 I keep hitting things that only a newer GCC fixes: subword atomics, some _Float16/RVV intrinsics, where GCC 13 fails and 14/15 is clean. So if a minimum-version pass starts throwing odd compile errors, suspect the compiler version early. Your "GCC 15 first, walk back after" instinct matches what I've seen.

    Ping me whenever there's something to test.
21. eshattow commented on Jul 10, 2026

    

    eshattow

    on Jul 10, 2026

    More actions

    @gounthar writes:

    ...
    The offer stands, and I mean it concretely. Once you have a musl dist tarball, I can run it on native riscv64 hardware ... Sanitizers and the profiler are the ones I'd especially want to exercise there.

    One data point that might save you time on the walk-back. On riscv64 I keep hitting things that only a newer GCC fixes: subword atomics, some _Float16/RVV intrinsics, where GCC 13 fails and 14/15 is clean. So if a minimum-version pass starts throwing odd compile errors, suspect the compiler version early. Your "GCC 15 first, walk back after" instinct matches what I've seen.

    Ping me whenever there's something to test.

    Successful CI build just completed, artifacts live at https://github.com/rust-lang/rust/actions/runs/29105425755 quoting myself "Test with alpine docker image and apk add libatomic libgcc bash". I'd really like to see some failures if there are any as you suspect, thanks!
22. gounthar commented on Jul 10, 2026

    

    gounthar

    on Jul 10, 2026

    OwnerAuthor

    More actions

    Ran it on the F3 (SpaceMiT K1, native riscv64), and gave the gnu dist from the same run the same treatment so we have a comparison. musl inside an Alpine container, gnu inside ubuntu:24.04, both native riscv64. Your recipe was enough on the musl side: apk add libatomic libgcc bash and the dist installed and ran clean.

    What worked on both targets:

    • rustc 1.99.0-nightly (af6bde0aa), LLVM 22.1.8, cargo alongside it
    • hosts report correctly (riscv64gc-unknown-linux-musl and -gnu), target_env musl/gnu as expected
    • hello world compiles and runs, cargo build --release links and runs a fresh binary end to end
    • the profiler is present and functional on both: libprofiler_builtins ships in std, and -C instrument-coverage compiles, runs, and drops a valid .profraw

    The failures are the sanitizers, and they line up across gnu and musl:

    musl:  error: address sanitizer is not supported for this target
           error: leak sanitizer is not supported for this target
    gnu:   error: address sanitizer is not supported for this target
           error: leak sanitizer is not supported for this target
           error: thread sanitizer is not supported for this target
    

    These are rustc target-spec rejections (the SanitizerSet for both riscv64 linux targets is empty), not anything crashing at runtime on the silicon. So it reads as a target-definition decision rather than a hardware limitation, and it isn't specific to your musl work: the gnu target has the same gap today. Whether the sanitizer runtimes in compiler-rt are actually ready for riscv64 is a separate question, but right now rustc doesn't offer them for either target.

    Net: the toolchain and the profiler run clean on real K1 silicon for both targets. Happy to re-run against a later build or exercise anything else you want checked.

    👍React with 👍1Reacted by E Shattow
23. eshattow commented on Jul 25, 2026

    

    eshattow

    on Jul 25, 2026

    Last edited by eshattow

    More actions

    @gounthar https://static.rust-lang.org/dist/rust-nightly-riscv64gc-unknown-linux-musl.tar.xz is now available. I also sent an enabling PR to rustup but I'm not sure what is involved there if it needs a point release or what delay is expected before that goes live. I am depending on "the dust to settle" for rustup when I will then get to enabling the official docker rust image for riscv64.

    Would you kindly confirm the nightly build as above is working as expected?

    P.S. I guess rustup does not build or publish from changes to the rustup main source branch for Tier 2 until the next point release of rustup. Testing of rustup requires to build rustup and that requires cargo which is part of the nightly rust tools. Suggested to unpack and use the nightly tools installer then build rustup and use it to test with the nightly dist channel.
24. gounthar commented on Jul 31, 2026

    

    gounthar

    on Jul 31, 2026

    OwnerAuthor

    More actions

    Confirmed working. I pulled the published tarball onto the F3 (SpaceMiT K1, native riscv64) today and ran it in an Alpine container, same shape as the July test so the two line up.

    rustc 1.99.0-nightly (8ab9fdff5 2026-07-30) with LLVM 22.1.8, cargo 1.99.0-nightly (7c83d4cc0 2026-07-29). Host triple reports riscv64gc-unknown-linux-musl and target_env comes back musl. Hello world compiles and runs. cargo build --release links and runs a fresh binary end to end. The profiler still works too: -C instrument-coverage compiles, runs, and drops a valid .profraw. The tarball ships rustc, std, cargo, rustfmt, rust-analyzer, llvm-tools, clippy, miri, rust-analysis and llvm-bitcode-linker.

    Sanitizers are where they were last time. address, leak, thread and memory all get rejected by the target spec, same as on the gnu target, so nothing musl-specific and nothing that looks like the silicon.

    One thing worth folding into the recipe. apk add libatomic libgcc bash gets the toolchain running but not linking, because rustc shells out to cc and bare Alpine hasn't got one. My first pass died with error: linker 'cc' not found on every single compile step and I spent a minute blaming the dist before spotting my own container was the problem. Adding gcc musl-dev and everything went through. Nothing wrong on your side, but anyone following the recipe as written will walk into it.

    I can take the rustup side next if it helps: build it from source with this nightly cargo, then point it at the nightly channel. You have a much better read than I do on whether that is useful now or whether it is better to wait for the point release to settle.

    👍React with 👍1Reacted by E Shattow
25. eshattow commented on Aug 1, 2026

    

    eshattow

    on Aug 1, 2026

    Last edited by eshattow

    More actions

    Confirmed working. I pulled the published tarball onto the F3 (SpaceMiT K1, native riscv64) today and ran it in an Alpine container, same shape as the July test so the two line up.

    rustc 1.99.0-nightly (8ab9fdff5 2026-07-30) with LLVM 22.1.8, cargo 1.99.0-nightly (7c83d4cc0 2026-07-29). Host triple reports riscv64gc-unknown-linux-musl and target_env comes back musl. Hello world compiles and runs. cargo build --release links and runs a fresh binary end to end. The profiler still works too: -C instrument-coverage compiles, runs, and drops a valid .profraw. The tarball ships rustc, std, cargo, rustfmt, rust-analyzer, llvm-tools, clippy, miri, rust-analysis and llvm-bitcode-linker.

    Sanitizers are where they were last time. address, leak, thread and memory all get rejected by the target spec, same as on the gnu target, so nothing musl-specific and nothing that looks like the silicon.

    One thing worth folding into the recipe. apk add libatomic libgcc bash gets the toolchain running but not linking, because rustc shells out to cc and bare Alpine hasn't got one. My first pass died with error: linker 'cc' not found on every single compile step and I spent a minute blaming the dist before spotting my own container was the problem. Adding gcc musl-dev and everything went through. Nothing wrong on your side, but anyone following the recipe as written will walk into it.

    I can take the rustup side next if it helps: build it from source with this nightly cargo, then point it at the nightly channel. You have a much better read than I do on whether that is useful now or whether it is better to wait for the point release to settle.

    I think hosting a build of rustup is not very useful, so with making sure it works when built locally from a range of RISC-V hardware as due dilligence there's no other objective to doing so. We wait for October rust 1.99 release or maybe the stable 1.99.1 after that, and rustup support to get a release following that.

    P.S. the rustup build also needs openssl-dev and either build-base for the overly broad range of packages or can be more specific
26. gounthar commented on Aug 3, 2026

    

    gounthar

    on Aug 3, 2026

    OwnerAuthor

    More actions

    Built it from source on the F3 (SpaceMiT K1, native riscv64) rather than hosting anything, since building locally was the part you said had value.

    Did both targets. Took the published nightly dist, built rustup from source at e3f8b81d8, then used the resulting rustup-init to install the nightly channel and compile through it. Both work. rustup show reports the right default host each time, nightly active, and a hello world plus a cargo build --release go through the rustup shims fine. Checked the tarballs against the published .sha256 before unpacking.

    Build times, native, nothing cross-compiled: musl 42m50s wall and 8244s user CPU, gnu 39m05s wall and 7631s user CPU, both peaking around 1.9 GB RSS.

    Scope caveat though, and it's a real one: this is one board, one K1. You asked about a range of RISC-V hardware and one F3 isn't that. My second board is the same silicon so it wouldn't tell us anything new. If you had particular hardware in mind, I can't cover it.

    One thing for the recipe, same spirit as the gcc musl-dev note. busybox tar in Alpine can't unpack the dist tarball at this size, dies with tar: corrupted data / short read even though the download is intact and the checksum matches. apk add tar or decompressing in two steps fixes it. Might be worth knowing for the docker image work.

    Agreed on parking the rest until the October release and a rustup release after it.
27. eshattow commented on Aug 21, 2026

    

    eshattow

    on Aug 21, 2026

    More actions

    chardet has published wheels for riscv64 with the recent release and may be marked as completed
28. gounthar commented on Aug 24, 2026

    

    gounthar

    on Aug 24, 2026

    OwnerAuthor

    More actions

    chardet 7.6.0 has riscv64 wheels for cp310 through cp315, and they go back to 7.3.0 in March. So it has been done for five months while the board still said otherwise. Marked it.

    Checked the rest of the list while I was in there. Seven others have shipped: fastar, rapidfuzz, jiter, blake3, tree-sitter, pyzmq (27.2.0, two days ago) and greenlet. All eight are now in a new "On PyPI" section.

    sqlalchemy is the odd one out. PR merged in March, but 2.0.52 from 2026-08-11 still ships no riscv64 wheel. No idea why yet.

    Thanks for the nudge.
29. gounthar

    added a commit that references this issue on Aug 24, 2026

    chore: stop building wheels upstream now publishes (#17)

    ...

    47d5299
30. luhenry commented on Aug 25, 2026

    

    luhenry

    on Aug 25, 2026

    More actions

    FYI if you haven't seen, Python has officially announced support for RISC-V: https://blog.python.org/2026/08/riscv-now-officially-supported/

    I'm also using https://stanfromireland.github.io/riscv-wheels/ to track which wheels to add. I'm adding them straight to https://github.com/riseproject-dev/python-wheels.
31. eshattow commented on Oct 1, 2026

    

    eshattow

    on Oct 1, 2026

    Last edited by eshattow

    More actions

    @gounthar writes:

    Agreed on parking the rest until the October release and a rustup release after it.

    Completed as of rustup 1.29.1 tagged 1st Sep 2026 for nightly channel of rust toolchain; The official rust 1.99 compiler release today 1st Oct 2026 enables the default channel of stable releases for riscv64 musl installation. On e.g. Alpine Linux this is simply apk add curl ca-certificates musl-dev gcc then follow the https://rustup.rs/ instructions. Also the docker-rust changes for this have been merged for whenever those images get built and pushed to Docker Hub corresponding to the rust compiler 1.99 release and tomorrow's nightly build for GitHub Container Registry.

    Update 5th Oct 2026: https://hub.docker.com/_/rust/tags?name=alpine images are live now

    🚀React with 🚀2Reacted by Bruno Verachten and Trevor Gamblin