multiprocess riscv64 support #270

Activity

1. github-actions

   added

   wheel

   riscv64-checkIssue opened during automatic scan of PyPI + RISE RegistryIssue opened during automatic scan of PyPI + RISE Registry

   on Aug 19, 2026
2. github-project-automation

   added this to Python Wheels - riseproject-dev/python-wheelson Aug 19, 2026
3. github-project-automation

   moved this to Todo in Python Wheels - riseproject-dev/python-wheelson Aug 19, 2026
4. threexc

   marked this as blocking on Aug 20, 2026

   • build top 50 Python binary wheels #72
5. luhenry commented on Aug 24, 2026

   

   luhenry

   on Aug 24, 2026

   Last edited by luhenry

   Member

   More actions

   No riscv64 build needed — multiprocess is pure-Python for CPython

   Investigated for a RISE riscv64 port. Conclusion: this is a false positive from the monthly checker, not a real gap. multiprocess ships universal py3-none-any wheels for CPython, which already install and run on riscv64 from PyPI today.

   Evidence:

   1. Upstream never compiles the C extension. setup.py ends with run_setup(False) in both the try and the except branch — with_extensions is always False, so the _multiprocess extension is never built.
   2. That extension is only a vendored copy of stdlib _multiprocessing. The package does try: import _multiprocess as _multiprocessing / except ImportError: import _multiprocessing and falls back to CPython's own stdlib extension (always present). The dill-based serialization — the reason the fork exists — is entirely in the pure-Python layer.
   3. PyPI CPython wheels are py3.9–py3.14 none-any. Built locally from the 0.70.19 sdist → multiprocess-0.70.19-py3-none-any.whl, Root-Is-Purelib: true, no .so; imports and runs Pool.map on riscv64.
   4. Why the checker flagged it: pypi_riscv64_check.py treats a package as "has binary wheels" if any wheel isn't none-any. multiprocess's only non-none-any wheels are PyPy builds (pp39/pp310/pp311, macOS + manylinux_2_28_x86_64) — none riscv64. This repo builds CPython wheels only, where every multiprocess wheel is none-any. Per the checker's own all-none-any skip policy (analyse_package returns None), CPython multiprocess should be treated as pure-Python.

   Recurrence note: find_existing_issue() matches only open issues, so the monthly pypi-riscv64-check (--create-issues) will re-file this every run because the PyPy wheels keep it in missing. To stop that permanently, either add multiprocess to an allowlist or refine the heuristic to ignore pp* (PyPy) wheels when deciding whether a CPython-only build repo has a gap.
6. luhenry

   closed this as not plannedon Aug 24, 2026
7. github-project-automation

   moved this from Todo to Available Upstream in Python Wheels - riseproject-dev/python-wheelson Aug 24, 2026