Thanks Ralf! I think this is great and mostly jibes with my understanding. It may help to add some text to the “unsupported platforms” section that gives us leeway to delete code for previously-supported platforms that we believe no one is using anymore. For example, for code supporting pypy in a few years, to the extent that existing code for pypy doesn’t get repurposed for things like limited API support.
On Fri, Jan 30, 2026 at 11:26 AM Ralf Gommers via NumPy-Discussion < [email protected]> wrote: > Hi all, > > There are quite a few open requests for adding support for more platforms, > either in CI or distributing wheels on PyPI. It seemed high time to define > a support policy. Both for us to be able to make decisions and document a > list of supported platforms, and for the people asking for support to > understand how we think about this topic. > > The immediate trigger for this NEP was > https://github.com/numpy/numpy/issues/22318 (request to support ppc64le > wheels), however this is already long overdue and there are a number of > open issues/PRs as well as known headaches or decisions we recently made, > e.g. Windows arm64 and x86, and macOS x86-64. > > This is a rough draft that I put together in an hour or two, drawing > primarily from PEP 11 and other recent write-ups (all linked under > Discussion). I'd like to discuss the main principles first before spending > more time on polishing the text. > > PR at https://github.com/numpy/numpy/pull/30748. Full text below: > > > =============================== > NEP 57 — NumPy platform support > =============================== > > :Author: Ralf Gommers <[email protected]> > :Status: Draft > :Type: Process > :Created: 2026-01-30 > :Resolution: - > > .. note:: > > This NEP is drafted as a policy specific to NumPy rather than a SPEC > for several reasons that are all project-specific: > > * it involves committing to a nontrivial amount of maintainer effort, > * personal commitment from a maintainer may make the difference between > a > yes and a no of supporting a platform (e.g., NumPy supported PyPy for > a > long time because of the efforts of one maintainer) > * support for a platform being possible at all may depend on features > of the > code base (e.g., NumPy supports 32-bit Python on Windows while SciPy > does > not because there's no suitable compiler toolchain for it) > * the number of wheels depends on whether the Stable ABI can be used > (NumPy > is more performance-sensitive for small arrays, so can't use it) > > > Abstract > -------- > > This PEP documents how a platform - i.e., a specific operating system, CPU > architecture and CPython interpreter - becomes supported in NumPy, what > platforms are currently supported, and were supported in the (recent) past. > > > Motivation and scope > -------------------- > > *This policy is being drafted now because there is a lot of interest in > extending the number of platforms NumPy supports through wheels in > particular.* > > The scope of this NEP includes: > > - The definition of tiers of support for platforms by NumPy > - Policies and decision making for moving a platform to a different tier > > Out of scope for this NEP are: > > - Binary distributions of NumPy outside of PyPI > - Partial testing in CI (e.g., testing only SIMD-specific code under QEMU) > - More detailed breakdowns of wheels and support matrices, like compiler > flavor > and minimum version, or the BLAS library that is used in the build. > > > Support tiers > ------------- > > *This section is inspired by PEP 11 (CPython platform support), although > definitions are not matching, because NumPy is not nearly as large a > project as > CPython.* > > Platform support is broken down into tiers. Each tier comes with different > requirements which lead to different promises being made about support. > > To be promoted to a tier, steering council support is required and is > expected > to be driven by team consensus. Demotion to a lower tier occurs when the > requirements of the current tier are no longer met for a platform for an > extended period of time based on the judgment of the steering council. For > platforms which no longer meet the requirements of any tier by the middle > of a > new feature release cycle, an announcement will be made to warn the > community > of the pending removal of support for the platform. If the platform is not > brought into line for at least one of the tiers by the first release > candidate, > it will be listed as unsupported in this NEP. > > > General principles > ~~~~~~~~~~~~~~~~~~ > > 1. Maintainer effort is expensive, and we collectively have limited > bandwidth - > hence platform support is strongly influenced by the willingness of one > or > more maintainers to put in that effort. > > - Maintainers are trusted by the whole team. We generally do not > question > *why* a maintainer is motivated to put in the effort. If they are > being > paid for their effort or doing it as part of their job, that is fine - > however they should disclose this to the Steering Council, and > indicate > whether long-term support is conditional on their employment or > contractor > status for the support tiers that include releasing wheels to PyPI. > *Rationale: releasing wheels to PyPI is a long-term commitment by the > project as a whole, see the backwards compatibility section below.* > > 2. CI support with native runners for the platform is strongly preferred. > Free > is best, however decisions on paid CI are up to the Steering Council. > Emulation for running the test suite (e.g., under QEMU) or self-hosted > buildbots are slower and less reliable, hence not preferred. > > 3. There should be broad enough demand for support for the platform for the > tiers that include releasing wheels to PyPI. > > - A previously used rule of thumb: >=0.5% of the user base should be on > this > platform. There may be reasons to deviate from this rule of thumb. > > 4. Adding a non-wheel CI job for a platform to the NumPy CI matrix is much > cheaper, and easily reverted in case of problems. The bar for adding > such > jobs is low, and assessed on a case-by-case basis. > > 5. For all platforms in any supported tier: the relevant prerequisites in > our > dependencies have been met. E.g., build tools have support, and for > wheels > there is support in CPython, PyPI, cibuildwheel, manylinux, and > ``scipy-openblas64`` or another easily-integrated BLAS library. > > 6. Decision making: > > - Moving a platform to a lower support tier must be discussed on the > mailing list. > - Moving a platform to a higher support tier this includes releasing > wheels > on PyPI for that platform must be discussed on the mailing list. > - Adding an entry for a platform for an unsupported platform or one > without > wheels can be done on GitHub, assuming it's clear from the discussion > that > the relevant maintainers agree. > > > Tier 1 > ~~~~~~ > > - Must have regular CI support on GitHub or (exceptionally) through another > well-integrated CI platform that the release team and steering council > deem > acceptable. > - The NumPy team releases wheels on PyPI for this platform > - CI failures (either regular CI or wheel build CI) block releases. > - All maintainers developers are responsible to keep the ``main`` branch > and > wheel builds working. > > Tier 1 platforms: > > - Windows x86-64 > - Windows arm64 > - Windows x86 (32-bit Python: note this is shipped without BLAS, it's > legacy) > - Linux x86-64 (manylinux) > - Linux aarch64 (manylinux) > - macOS arm64 > - macOS x86-64 (expected to move to unsupported by 2027/28 once the > platform is dropped by GitHub) > > > Tier 2 > ~~~~~~ > > - Must have regular CI support, either as defined for Tier 1 or through a > reliable self-hosted service. > - The NumPy team releases wheels on PyPI for this platform > - CI failures block releases. > - Must have at least one maintainer who commits to take primary and > long-term > responsibility for keeping the ``main`` branch and wheel builds working. > > Tier 2 platforms: > > - Linux x86-64 (musllinux) > - Linux aarch64 (musllinux) > - Free-threaded CPython > > > Tier 3 > ~~~~~~ > > - Is supported as part of NumPy's regular CI setup for the ``main`` > branch. CI > support as defined for Tier 2. > - No wheels are released on PyPI for this platform > - CI failures block releases (skips may be applied a bit more liberally). > - Must have at least one maintainer or a regular contributor trusted by the > NumPy maintainers who commits to take responsibility for CI on the > ``main`` > branch working. > > Tier 3 platforms: > > - FreeBSD (note: runs on Cirrus CI) > - Linux ppc64le (note: runs on IBM-provided self-hosted runners) > - Emscripten/Pyodide > > > Unsupported platforms > ~~~~~~~~~~~~~~~~~~~~~ > > All platforms not listed in the above tiers are unsupported by the NumPy > team. > We do not develop and test on such platforms, and so cannot provide any > promises that NumPy will work on them. > > However, the code base does include unsupported code – that is, code > specific > to unsupported platforms. Contributions in this area are welcome as long as > they: > > - pose a minimal maintenance burden to the core team, and > - benefit substantially more people than the contributor. > > Unsupported platforms (previously in a supported tier, may be an incomplete > list): > > - PyPy > - macOS ppc64, universal, universal2 > - Linux i686 > - Linux on IBM Z (s390x) > > Unsupported platforms (known interest in moving to a higher tier): > > - iOS > - Android > - RISC-V > - WASI > > > Backward compatibility > ---------------------- > > Moving a platform to a lower tier of support is generally backwards > compatible. > The exception is stopping to release wheels on PyPI for a platform. That > causes > signifcant disruption for existing users on that platform. Their install > commands > (e.g., ``pip install numpy``) may stop working because if a new release no > longer > has wheels for the platform, by default ``pip`` will try to build from > source rather > than using a wheel from an older version of ``numpy``. Therefore, we > should be very > reluctant to drop wheels for any platform. > > > Discussion > ---------- > > - `ENH: Provide Windows ARM64 wheels (numpy#22530) < > https://github.com/numpy/numpy/issues/22530>`__ > - `Releasing PowerPC (ppc64le) wheels? (numpy#22318) < > https://github.com/numpy/numpy/issues/22318>`__ > - `MAINT: drop support for PyPy (numpy#30416) < > https://github.com/numpy/numpy/issues/30416>`__ > - `ENH: Build and distribute manylinux wheels for riscv64 < > https://github.com/numpy/numpy/issues/30216>`__ > - `BLD: Add support for building iOS wheels (numpy#28759) < > https://github.com/numpy/numpy/pull/28759>`__ > - `BLD: Add Android support <https://github.com/numpy/numpy/pull/30412>`__ > - `ENH: WASI Build <https://github.com/numpy/numpy/issues/25859>`__ > - `PEP 11 - CPython platform support <https://peps.python.org/pep-0011/ > >`__ > - `Debian's supported architectures < > https://wiki.debian.org/SupportedArchitectures>`__ > - `Discussion about supported platforms for wheels (scientific-python > issue/discussion (Nov 2025) < > https://github.com/scientific-python/summit-2025-nov/issues/4>`__ > - `What platforms should wheels be provided for by default? (Packaging > Discourse thread, 2026) < > https://discuss.python.org/t/what-platforms-should-wheels-be-provided-for-by-default/105822 > >`__ > - `Expectations that projects provide ever more wheels > (pypackaging-native) < > https://pypackaging-native.github.io/meta-topics/user_expectations_wheels/ > >`__ > > > _______________________________________________ > NumPy-Discussion mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3//lists/numpy-discussion.python.org > Member address: [email protected] >
_______________________________________________ NumPy-Discussion mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: [email protected]
