Good question - I assume the answer will strongly depend on build complexity and whether one wants to optimize for the average OSS maintainer or for projects with paid dev time behind them. I’d hope for the former, meaning that tools aimed at distribution shouldn’t use overly inclusive defaults.
This thread summarizes the considerations and current status for the scientific ecosystem: Discussion about supported platforms for wheels · Issue #4 · scientific-python/summit-2025-nov · GitHub. I’ll repost the most relevant part of my summary of what’s NOT currently supported but may be considered here (modulo win-arm64 which has now been accepted by most projects):
- PowerPC (
ppc64le): supported for a long time, but a funded (IBM) push over the past 6 months - Windows on Arm64: new-ish and GitHub Actions support quite new, with funded (Microsoft) push
- RISC-V: coming to PyPI probably, has funding - see https://riseproject.dev/2025/05/14/easy-installation-of-binary-python-packages-on-riscv64-devices and Packaging support for riscv64 - #13 by markdryan
- iOS: new (PEP 730), see also Bringing Python to iOS and Android with BeeWare | Anaconda about both iOS and Android
- Android: new (PEP 738)
- Emscripten: in the pipeline, see PEP 783
Platforms for which we’ve mostly dropped support by now:
- PyPy: it’s essentially end-of-life, won’t go beyond support Python 3.11
- 32-bit x86 Linux (
i686): still testing in CI, but there’s no real demand, wheels were dropped - 32-bit x86 Windows:
numpystill publishes wheels, most other projects do not.
Platforms which have had support for a long time but most projects never supported wheels for and without a push for change:
- IBM-Z (
s390x): well maybe IBM would like a push if theirppc64lepush succeeds, buts390xis really too niche - 32-bit Arm on Linux (
armv7l): has wheels on https://piwheels.org/, no real discussion on moving that upstream.