You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
PyPI CPython wheels are py3.9–py3.14none-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.
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.
Activity
luhenry commentedon Aug 24, 2026
No riscv64 build needed —
multiprocessis pure-Python for CPythonInvestigated for a RISE riscv64 port. Conclusion: this is a false positive from the monthly checker, not a real gap.
multiprocessships universalpy3-none-anywheels for CPython, which already install and run on riscv64 from PyPI today.Evidence:
setup.pyends withrun_setup(False)in both thetryand theexceptbranch —with_extensionsis alwaysFalse, so the_multiprocessextension is never built._multiprocessing. The package doestry: import _multiprocess as _multiprocessing / except ImportError: import _multiprocessingand 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.py3.9–py3.14none-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 runsPool.mapon riscv64.pypi_riscv64_check.pytreats a package as "has binary wheels" if any wheel isn'tnone-any.multiprocess's only non-none-anywheels are PyPy builds (pp39/pp310/pp311, macOS +manylinux_2_28_x86_64) — none riscv64. This repo builds CPython wheels only, where everymultiprocesswheel isnone-any. Per the checker's own all-none-anyskip policy (analyse_packagereturnsNone), CPythonmultiprocessshould be treated as pure-Python.Recurrence note:
find_existing_issue()matches only open issues, so the monthlypypi-riscv64-check(--create-issues) will re-file this every run because the PyPy wheels keep it inmissing. To stop that permanently, either addmultiprocessto an allowlist or refine the heuristic to ignorepp*(PyPy) wheels when deciding whether a CPython-only build repo has a gap.