PEP 513

PEP 513 PEP 513 proposed adding support for manylinux1 wheels to the Python package ecosystem to simplify distribution of precompiled binary extensions across Linux distributions. The proposal aimed to standardize a portable binary format enabling projects that include C extensions to distribute wheels compatible with a wide range of Debian, Ubuntu, Red Hat Enterprise Linux, Fedora, CentOS, Amazon Linux, SUSE Linux Enterprise Server users. It connected packaging tools and infrastructure such as pip (software), setuptools, Wheel (Python) and the Python Package Index to foster reproducible installation workflows used by projects like NumPy, Pandas, SciPy, and TensorFlow.

Background

Before the proposal, binary distribution on Linux suffered from ABI and libc differences among distributions like Debian, Red Hat Enterprise Linux, Ubuntu, CentOS, SUSE Linux Enterprise Server, and Amazon Linux. Packaging initiatives including Wheel (Python), PEP 427, pip (software), setuptools, distutils and ecosystem projects such as NumPy, SciPy, Pandas, Matplotlib worked to reduce friction for users installing packages with compiled extensions. Distribution maintainers from Red Hat, Canonical (company), SUSE, and community projects such as Fedora Project and Debian Project influenced interactions between upstream maintainers and distribution packages. Prior art such as manylinux efforts and compatibility levels provided a precedent that intersected with standards established in PEP 427 and the wider Python Software Foundation ecosystem.

Motivation

The motivation centered on interoperability among widely used Linux distributions and packaging tools. Package authors and projects like NumPy, Pandas, SciPy, Matplotlib, scikit-learn, TensorFlow, PyTorch, and organizations including the Python Software Foundation and Anaconda, Inc. sought a way to distribute prebuilt binary wheels that would install cleanly on user systems from disparate bases such as Debian, Ubuntu, Red Hat Enterprise Linux, CentOS, SUSE Linux Enterprise Server, Amazon Linux without requiring users to install build toolchains like GCC, clang, GNU Make or development headers. The proposal intended to reduce reliance on distribution-specific packaging mechanisms used by APT (software), RPM (file format), and third-party binary repositories, improving developer workflows for continuous integration platforms such as Jenkins, Travis CI, CircleCI, and GitHub Actions.

Specification

The specification defined a platform tag identifying a baseline compatibility using an older stable GNU C Library ABI as found on long-term-support distributions. It described constraints for building wheels: linking only to allowed libraries present on target systems like the GNU C Library used by Red Hat Enterprise Linux and avoiding newer symbols introduced in later libc versions. The format leveraged standards from PEP 427 and wheel tags as implemented in Wheel (Python) and tools like pip (software) and setuptools. The spec laid out build-time environment requirements referencing containerization and build hosts such as Docker (software), base images aligning with CentOS or Red Hat Enterprise Linux runtime behavior, and produced tags for the Python Packaging Index used by PyPI to advertise compatibility to clients.

Implementation

Implementation involved changes to tooling and build pipelines: updates to pip (software) to recognize and prefer compatible wheels, enhancements to wheel building utilities in setuptools or wheel (software), and continuous integration setups in projects like NumPy and SciPy to produce compliant artifacts. Community infrastructure such as PyPI, packaging services used by Travis CI, CircleCI, and GitHub Actions integrated the produced manylinux1-style wheels. Build environments were implemented using containerization tools like Docker (software) based on images from CentOS or related vendor-provided images, and packagers coordinated with distribution maintainers at Red Hat, Canonical (company), and SUSE for validation against system ABIs. Major scientific and data projects, including Pandas, Matplotlib, scikit-learn, and scipy.org toolchains adopted the outputs to expedite user installs.

Compatibility and Platform Support

The approach prioritized backward-compatible ABIs commonly available on enterprise and LTS distributions including Red Hat Enterprise Linux, CentOS, Ubuntu LTS, Debian Stable, SUSE Linux Enterprise Server, and Amazon Linux. It explicitly avoided reliance on newer symbols introduced in later releases of the GNU C Library to maximize reach across distributions and cloud providers like Amazon Web Services, Google Cloud Platform, and Microsoft Azure. Client tooling updates in pip (software) and wheel metadata ensured that installers could select compatible wheels by platform tag, while CI and build orchestration systems in projects such as NumPy, Pandas, SciPy automated artifact production for multiple Python implementations including CPython, PyPy where applicable.

Security Considerations

Security considerations encompassed supply-chain risks, binary provenance, and runtime compatibility. Mitigations included reproducible build practices, use of controlled build images from trusted vendors such as Red Hat and CentOS Project, signing and verification mechanisms supported by PyPI client tooling, and recommendations to avoid bundling outdated or vulnerable third-party libraries. Coordination with security incident responders at organizations like Ubuntu, Red Hat, SUSE, and processes influenced by bodies such as the Python Software Foundation and ecosystem projects reduced the attack surface. Runtime behavior across distributions was vetted to prevent symbol-level conflicts or unintended use of platform-provided libraries that could introduce vulnerabilities.

Category:Python Enhancement Proposals