What platforms should wheels be provided for by default?

Packaging
1

This post is motivated noticing that PPC64 is semi-supported by manylinux (Why is PPC64 only supported for manylinux 2.17? · Issue #669 · pypa/auditwheel · GitHub), while being apparently a dead platform not supported by Linux distributions anymore.

Generally, the platform support in public packages is limited by the wheel tags that PyPI accepts. The question is, what tags should we build for by default? The platform support of Rust/C/C++ and the platform support encoded in packaging tools is larger than that of PyPI, but for CI complexity, release performance and release size (PyPI has size limits), I’m looking for what should be the recommended default set of platforms to build wheels for.

Personally, I’m thinking about both the platforms that uv provides wheels for and the ones that maturin(-action) should include the defaults, but I’m sure there are more cases with the same problems. There may also be a difference in whether you’re shipping a standalone binary or an extension module?

The obvious ones to support are:

  • Linux x86_64
  • Linux arm64
  • macOS x86_64 (though this may get deprecate at some point as apple drop support?)
  • macOS arm64
  • Windows x86_64
  • Windows arm64 (Slow start, but there’s increasing consumer hardware with it such as arm notebooks)

Supported by PyPI, but clearly dead:

  • macOS PPC
  • macOS PPC64
  • macOS i386
  • Windows ia64

Other target - These are the ones where it’s interesting whether they should be supported by default:

New platforms - Support for them has been added recently, potentially relevant for extension modules but maybe not for standalone binaries?

  • iOS arm64 iphoneos
  • iOS arm64 iphonesimulator
  • iOS x86_64 iphonesimulator
  • Android armeabi_v7a
  • Android arm64_v8a
  • Android x86
  • Android x86_64
7 Likes
2

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):

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: numpy still 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 their ppc64le push succeeds, but s390x is really too niche
  • 32-bit Arm on Linux (armv7l): has wheels on https://piwheels.org/, no real discussion on moving that upstream.
2 Likes
3

What makes you think that Linux distributions stop supporting PPC64? The Fedora family (Fedora, CentOS Stream, RHEL, Alma, …) and Debian family (Debian, Ubuntu, …) have full support for Power ppc64le. PEP 11 lists ppc64le as Tier 3 platform, Rust even as a Tier 2 platform.

Maybe you got confused by the fact that PPC64 has two variants. ppc64le (little endian) is actively maintained and used in servers and super computers. ppc64be (big endian) is pretty much dead.

4

The naming in Python is confusing: PPC64 (no suffix) is big endian, while PPC64LE is little endian. The dead platform I’m referring to is the big endian PPC64, PPC64LE is still supported, I’ve explicitly listed both of them in the other targets list below.

1 Like
5

Thanks for clarifying! I agree with you, big endian Power has become irrelevant and is no longer supported. My last piece of hardware with a Power CPU was a PowerBook 25 year ago.

The acronyms are confusing and not consistently used. As I mentioned in the Ruff ticket, it leads to all sorts of confusion.

I have seen people generally PPC64 (upper case) to refer to the general 64bit Power platform. Big endian Power is commonly refer to as ppc64, ppc64be, or powerpc64. IIRC LLVM uses ppc64 internally. config.guess, LLVM’s, and therefore Rust’s platform triplet use powerpc64.

6

armv7l wheels are great for Beaglebone boards. I -think- some Raspberry Pi users will appreciate armv6l wheels too.

7

They’re also provided by piwheels.

1 Like
8

Wow, that is news to me. Do you have a reference?

3 Likes
9

I see no blog post with an official announcement on pypy.org yet, but here is a statement from Matti Picus (long-time maintainer of both PyPy and NumPy): “PyPy is no longer under active development, and has not released a Python3.12 version.” And the commit graph confirms: Contributors to pypy/pypy · GitHub

6 Likes
10

There’s also LoongArch64.

The supported CPU architectures in ‘packaging’ are:

1 Like
11

I don’t see any mentions of loongarch in warehouse, is it possible to publish loongarch64 wheels to PyPI?

12

Not yet, see: Path towards manylinux / PyPI support for loongarch64.

1 Like