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]
