Zusammenfassung

Dieses PEP schlägt die Erstellung eines manylinux2014 Plattform-Tags vor, um den in PEP 513 eingeführten manylinux2010 Tag zu ersetzen. Es schlägt außerdem vor, dass PyPI und pip beide aktualisiert werden, um das Hochladen, Herunterladen und Installieren von manylinux2014 Distributionen auf kompatiblen Plattformen zu unterstützen.

Begründung

CentOS 6 ist nun die älteste unterstützte CentOS-Version und erhält bis zum 30. November 2020 Wartungsaktualisierungen [1]. Danach erreicht es das Ende seiner Lebensdauer und keine weiteren Updates wie Sicherheitspatches werden verfügbar sein. Alle unter den manylinux2010 Images erstellten Wheels werden ab diesem Zeitpunkt veraltete Versionen bleiben.

Daher schlagen wir die Fortsetzung des bestehenden manylinux-Standards vor und dass ein neuer Plattform-Tag im Stil von PEP 425 mit dem Namen manylinux2014 von CentOS 7 abgeleitet wird und dass die manylinux Toolchain, PyPI und pip aktualisiert werden, um sie zu unterstützen.

Ähnlich wie PEP 571 und PEP 513 erlaubte, gemeinsam genutzte Bibliotheken und deren Symbolversionen von CentOS 5.11 bzw. CentOS 6 zu beziehen, wird ein manylinux2014 Plattform-Tag seine Bibliotheken und Symbolversionen von CentOS 7 beziehen, das am 30. Juni 2024 sein Lebensende erreicht. [1]

Das Muster manylinuxYYYY hat eine Reihe von Vorteilen, die die Fortsetzung des aktuellen Status Quo motivieren

• Gut definierte Docker-Images mit klar spezifizierten kompatiblen Bibliotheken;
• Keine Notwendigkeit, auf Kompatibilitätsprobleme über mehrere Versionen hinweg zu prüfen;
• Ein einzelnes Build-Image und ein auditwheel Profil pro Architektur.

Es gibt auch einige Nachteile

• Erfordert die Ausarbeitung eines neuen PEP für jeden neuen Standard;
• Erfordert das Hinzufügen des neuen Plattform-Tags zu Installern (z.B. pip);
• Installationsprogramme können kein Plattform-Tag installieren, das älter als eine bestimmte Version ist.

Es gibt auch Herausforderungen, die bei jedem Vorschlag bestehen würden, darunter der Zeit- und Arbeitsaufwand für die Definition, Vorbereitung und Veröffentlichung der Docker-Images und der entsprechenden auditwheel Profile. Diese Herausforderungen gab es während der langen Einführungszeit für manylinux2010, die etwa 1 Jahr von der Annahme des PEP bis zur Veröffentlichung einer kompatiblen Build-Umgebung dauerte. [3]

Wenn dieses PEP jedoch als Indikator dienen kann, ist der Prozess nun gut definiert und leicht wiederholbar, was die Einführungszeit für neuere, aktualisierte Plattform-Tags verkürzen sollte.

Die manylinux2014 Politik

Die folgenden Kriterien bestimmen die Eignung eines linux Wheels für das manylinux2014 Tag

1. Das Wheel darf nur kompilierte Binärdateien und gemeinsam genutzte Objekte enthalten, die für eine der folgenden Architekturen kompiliert wurden, die von CentOS 7 oder einer CentOS 7-kompatiblen Basis-Image (wie ubi7) unterstützt werden: [4]

   x86_64
   i686
   aarch64
   armv7l
   ppc64
   ppc64le
   s390x
   

   Diese Liste fügt Unterstützung für ARMv7 (armv7l), ARMv8 (aarch64) und PowerPC (ppc64, ppc64le) Architekturen hinzu, die vom CentOS Alternative Architecture Special Interest Group unterstützt werden, sowie die IBM Z (s390x) Architektur. [5]

2. Die Binärdateien oder gemeinsam genutzten Objekte des Wheels dürfen nicht gegen extern bereitgestellte Bibliotheken verknüpft werden, außer denen in der folgenden Liste

   libgcc_s.so.1
   libstdc++.so.6
   libm.so.6
   libdl.so.2
   librt.so.1
   libc.so.6
   libnsl.so.1
   libutil.so.1
   libpthread.so.0
   libresolv.so.2
   libX11.so.6
   libXext.so.6
   libXrender.so.1
   libICE.so.6
   libSM.so.6
   libGL.so.1
   libgobject-2.0.so.0
   libgthread-2.0.so.0
   libglib-2.0.so.0
   

   Diese Liste ist identisch mit den extern bereitgestellten Bibliotheken, die ursprünglich für manylinux2010 zulässig waren, mit einer Ausnahme: libcrypt.so.1 wurde entfernt, da es in Fedora 30 als veraltet galt. libpythonX.Y bleibt aus den in PEP 513 dargelegten Gründen für die Aufnahme unzulässig.

   Auf Debian-basierten Systemen werden diese Bibliotheken von den Paketen bereitgestellt

   Paket	Bibliotheken
   libc6	libdl.so.2, libresolv.so.2, librt.so.1, libc.so.6, libpthread.so.0, libm.so.6, libutil.so.1, libnsl.so.1
   libgcc1	libgcc_s.so.1
   libgl1	libGL.so.1
   libglib2.0-0	libgobject-2.0.so.0, libgthread-2.0.so.0, libglib-2.0.so.0
   libice6	libICE.so.6
   libsm6	libSM.so.6
   libstdc++6	libstdc++.so.6
   libx11-6	libX11.so.6
   libxext6	libXext.so.6
   libxrender1	libXrender.so.1

   Auf RPM-basierten Systemen werden sie von diesen Paketen bereitgestellt

   Paket	Bibliotheken
   glib2	libglib-2.0.so.0, libgthread-2.0.so.0, libgobject-2.0.so.0
   glibc	libresolv.so.2, libutil.so.1, libnsl.so.1, librt.so.1, libpthread.so.0, libdl.so.2, libm.so.6, libc.so.6
   libICE	libICE.so.6
   libX11	libX11.so.6
   libXext	libXext.so.6
   libXrender	libXrender.so.1
   libgcc	libgcc_s.so.1
   libstdc++	libstdc++.so.6
   mesa	libGL.so.1

3. Wenn das Wheel Binärdateien oder gemeinsam genutzte Objekte enthält, die gegen zulässige Bibliotheken verknüpft sind, die auch versionierte Symbole exportieren, dürfen sie nur von den folgenden maximalen Versionen abhängen

   GLIBC_2.17
   CXXABI_1.3.7, CXXABI_TM_1 is also allowed
   GLIBCXX_3.4.19
   GCC_4.8.0
   

   Als Beispiel können manylinux2014 Wheels Binärartefakte enthalten, die glibc Symbole der Version GLIBC_2.12 erfordern, da dies eine frühere Version als das Maximum von GLIBC_2.17 ist.

4. Wenn ein Wheel für eine beliebige Version von CPython 2 oder CPython-Versionen 3.0 bis einschließlich 3.2 erstellt wird, *muss* es ein CPython ABI-Tag enthalten, das seine Unicode-ABI angibt. Ein manylinux2014 Wheel, das gegen Python 2 erstellt wurde, muss daher entweder das cpy27mu Tag enthalten, das angibt, dass es gegen einen Interpreter mit der UCS-4 ABI erstellt wurde, oder das cpy27m Tag, das einen Interpreter mit der UCS-2 ABI angibt. (PEP 3149 [7])
5. Ein Wheel darf das Symbol PyFPE_jbuf *nicht* erfordern. Dies wird erreicht, indem es gegen eine Python-Version kompiliert wird, die *ohne* das --with-fpectl configure Flag kompiliert wurde.

Kompilierung konformer Wheels

Wie bei manylinux1 fügt das auditwheel Werkzeug manylinux2014 Plattform-Tags zu linux Wheels hinzu, die von pip wheel oder bdist_wheel in einem manylinux2014 Docker-Container erstellt werden.

Plattformerkennung für Installer

Plattformen können ein boolesches Attribut manylinux2014_compatible im Modul _manylinux definieren, das in PEP 513 beschrieben ist. Eine Plattform gilt als inkompatibel mit manylinux2014, wenn das Attribut False ist.

Wenn das Modul _manylinux nicht gefunden wird oder das Attribut manylinux2014_compatible nicht hat, können Werkzeuge auf die Überprüfung von glibc zurückgreifen. Wenn die Plattform glibc 2.17 oder neuer hat, wird sie als kompatibel angenommen, es sei denn, das Modul _manylinux sagt etwas anderes.

Speziell ist der von uns vorgeschlagene Algorithmus

def is_manylinux2014_compatible():
    # Only Linux, and only supported architectures
    from distutils.util import get_platform

    if get_platform() not in [
        "linux-x86_64",
        "linux-i686",
        "linux-aarch64",
        "linux-armv7l",
        "linux-ppc64",
        "linux-ppc64le",
        "linux-s390x",
    ]:
        return False

    # Check for presence of _manylinux module
    try:
        import _manylinux

        return bool(_manylinux.manylinux2014_compatible)
    except (ImportError, AttributeError):
        # Fall through to heuristic check below
        pass

    # Check glibc version. CentOS 7 uses glibc 2.17.
    # PEP 513 contains an implementation of this function.
    return have_compatible_glibc(2, 17)

Abwärtskompatibilität mit manylinux2010 Wheels

Wie in PEP 513 erläutert, stellen die spezifizierten Symbolversionen für die von manylinux1 zulässigen Bibliotheken eine *Obergrenze* dar. Das Gleiche gilt für die in diesem PEP für manylinux2014 definierten Symbolversionen. Infolgedessen gelten manylinux1 und manylinux2010 Wheels als manylinux2014 Wheels. Ein pip, das das manylinux2014 Plattform-Tag erkennt, installiert daher manylinux2010 Wheels für manylinux2014 Plattformen – auch wenn sie explizit eingestellt sind –, wenn keine manylinux2014 Wheels verfügbar sind.

PyPI-Unterstützung

PyPI sollte das Hochladen von Wheels, die das manylinux2014 Plattform-Tag enthalten, auf die gleiche Weise zulassen, wie es manylinux2010 zulässt.

Wenn technisch machbar, sollte PyPI versuchen, die Kompatibilität von manylinux2014 Wheels zu überprüfen, aber diese Fähigkeit ist keine Voraussetzung für die Annahme dieses PEP.

Paketautoren sollten keine nicht konformen manylinux2014 Wheels auf PyPI hochladen und sollten sich bewusst sein, dass PyPI beginnen kann, das Hochladen von nicht konformen Wheels zu blockieren.

Referenzen

Akzeptanz

PEP 599 wurde am 31. Juli 2019 von Paul Moore angenommen.

Urheberrecht

Dieses Dokument wird in die Public Domain oder unter die CC0-1.0-Universal-Lizenz gestellt, je nachdem, welche Lizenz permissiver ist.