Skip to content

571: Update manylinux2 -> manylinux2010 #596

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Mar 19, 2018
Merged

571: Update manylinux2 -> manylinux2010 #596

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
be79a8d
Update manylinux2 -> manylinux2010
takluyver Mar 19, 2018
7ed3bd7
Add myself as an author on PEP 571
takluyver Mar 19, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 35 additions & 26 deletions pep-0571.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,8 +1,9 @@
PEP: 571
Title: The manylinux2 Platform Tag
Title: The manylinux2010 Platform Tag
Version: $Revision$
Last-Modified: $Date$
Author: Mark Williams <mrw@enotuniq.org>
Author: Mark Williams <mrw@enotuniq.org>,
Thomas Kluyver <thomas@kluyver.me.uk>
BDFL-Delegate: Nick Coghlan <ncoghlan@gmail.com>
Discussions-To: Distutils SIG <distutils-sig@python.org>
Status: Active
Expand All @@ -16,10 +17,10 @@ Resolution:
Abstract
========

This PEP proposes the creation of a ``manylinux2`` platform tag to
This PEP proposes the creation of a ``manylinux2010`` platform tag to
succeed the ``manylinux1`` tag introduced by PEP 513 [1]_. It also
proposes that PyPI and ``pip`` both be updated to support uploading,
downloading, and installing ``manylinux2`` distributions on compatible
downloading, and installing ``manylinux2010`` distributions on compatible
platforms.

Rationale
Expand Down Expand Up @@ -52,16 +53,24 @@ packagers who use the ``manylinux1`` Docker image.

CentOS 6 is now the oldest supported CentOS release, and will receive
maintenance updates through November 30th, 2020. [5]_ We propose that
a new PEP 425-style [6]_ platform tag called ``manylinux2`` be derived
a new PEP 425-style [6]_ platform tag called ``manylinux2010`` be derived
from CentOS 6 and that the ``manylinux`` toolchain, PyPI, and ``pip``
be updated to support it.

This was originally proposed as ``manylinux2``, but the versioning has been
changed to use calendar years. This makes it easier to define future *manylinux*
tags out of order: e.g. ``manylinux2017`` may be defined before
``manylinux2014`` (both hypothetical). It also gives a rough idea of which Linux
distribution versions support which tag: ``manylinux2010`` will work on most
distribution versions released since 2010. This is only an approximation,
however: the actual compatibility rules are defined below, and some newer
distributions may not meet them.

The ``manylinux2`` policy
=========================
The ``manylinux2010`` policy
============================

The following criteria determine a ``linux`` wheel's eligibility for
the ``manylinux2`` tag:
the ``manylinux2010`` tag:

1. The wheel may only contain binary executables and shared objects
compiled for one of the two architectures supported by CentOS 6:
Expand Down Expand Up @@ -142,12 +151,12 @@ the ``manylinux2`` tag:
GLIBCXX_3.4.13
GCC_4.3.0

As an example, ``manylinux2`` wheels may include binary artifacts
As an example, ``manylinux2010`` wheels may include binary artifacts
that require ``glibc`` symbols at version ``GLIBC_2.4``, because
this an earlier version than the maximum of ``GLIBC_2.12``.
4. If a wheel is built for any version of CPython 2 or CPython
versions 3.0 up to and including 3.2, it *must* include a CPython
ABI tag indicating its Unicode ABI. A ``manylinux2`` wheel built
ABI tag indicating its Unicode ABI. A ``manylinux2010`` wheel built
against Python 2, then, must include either the ``cpy27mu`` tag
indicating it was built against an interpreter with the UCS-4 ABI
or the ``cpy27m`` tag indicating an interpeter with the UCS-2
Expand All @@ -159,16 +168,16 @@ the ``manylinux2`` tag:
Compilation of Compliant Wheels
===============================

Like ``manylinux1``, the ``auditwheel`` tool adds ```manylinux2``
Like ``manylinux1``, the ``auditwheel`` tool adds ```manylinux2010``
platform tags to ``linux`` wheels built by ``pip wheel`` or
``bdist_wheel`` in a ``manylinux2`` Docker container.
``bdist_wheel`` in a ``manylinux2010`` Docker container.

Docker Images
-------------

``manylinux2`` Docker images based on CentOS 6 x86_64 and i686 are
``manylinux2010`` Docker images based on CentOS 6 x86_64 and i686 are
provided for building binary ``linux`` wheels that can reliably be
converted to ``manylinux2`` wheels. [10]_ These images come with a
converted to ``manylinux2010`` wheels. [10]_ These images come with a
full compiler suite installed (``gcc``, ``g++``, and ``gfortran``
4.8.2) as well as the latest releases of Python and ``pip``.

Expand Down Expand Up @@ -225,13 +234,13 @@ packagers will not be able to use our Docker images there to build

We have derived a patch from the ``glibc`` git repository that
backports the removal of all dependencies on ``vsyscall`` to the
version of ``glibc`` included with our ``manylinux2`` image. [20]_
Rebuilding ``glibc``, and thus building ``manylinux2`` image itself,
version of ``glibc`` included with our ``manylinux2010`` image. [20]_
Rebuilding ``glibc``, and thus building ``manylinux2010`` image itself,
still requires a host kernel that provides the ``vsyscall`` mechanism,
but the resulting image can be both run on hosts that provide it and
those that do not. Because the ``vsyscall`` interface is an
optimization that is only applied to running processes, the
``manylinux2`` wheels built with this modified image should be
``manylinux2010`` wheels built with this modified image should be
identical to those built on an unmodified CentOS 6 system. Also, the
``vsyscall`` problem applies only to x86_64; it is not part of the
i686 ABI.
Expand All @@ -240,16 +249,16 @@ Auditwheel
----------

The ``auditwheel`` tool has also been updated to produce
``manylinux2`` wheels. [21]_ Its behavior and purpose are otherwise
``manylinux2010`` wheels. [21]_ Its behavior and purpose are otherwise
unchanged from PEP 513.


Platform Detection for Installers
=================================

Platforms may define a ``manylinux2_compatible`` boolean attribute on
Platforms may define a ``manylinux2010_compatible`` boolean attribute on
the ``_manylinux`` module described in PEP 513. A platform is
considered incompatible with ``manylinux2`` if the attribute is
considered incompatible with ``manylinux2010`` if the attribute is
``False``.


Expand All @@ -258,19 +267,19 @@ Backwards compatibility with ``manylinux1`` wheels

As explained in PEP 513, the specified symbol versions for
``manylinux1`` whitelisted libraries constitute an *upper bound*. The
same is true for the symbol versions defined for ``manylinux2`` in
same is true for the symbol versions defined for ``manylinux2010`` in
this PEP. As a result, ``manylinux1`` wheels are considered
``manylinux2`` wheels. A ``pip`` that recognizes the ``manylinux2``
``manylinux2010`` wheels. A ``pip`` that recognizes the ``manylinux2010``
platform tag will thus install ``manylinux1`` wheels for
``manylinux2`` platforms -- even when explicitly set -- when no
``manylinux2`` wheels are available. [22]_
``manylinux2010`` platforms -- even when explicitly set -- when no
``manylinux2010`` wheels are available. [22]_

PyPI Support
============

PyPI should permit wheels containing the ``manylinux2`` platform tag
PyPI should permit wheels containing the ``manylinux2010`` platform tag
to be uploaded in the same way that it permits ``manylinux1``. It
should not attempt to verify the compatibility of ``manylinux2``
should not attempt to verify the compatibility of ``manylinux2010``
wheels.


Expand Down