Zusammenfassung

Dieses PEP spezifiziert ein Tagging-System, um anzugeben, mit welchen Python-Versionen eine kompilierte oder binäre Distribution kompatibel ist. Eine Reihe von drei Tags gibt an, welche Python-Implementierung und Sprachversion, ABI und Plattform eine kompilierte Distribution benötigt. Die Tags sind kurz gehalten, da sie in Dateinamen enthalten sein werden.

PEP-Akzeptanz

Dieses PEP wurde von Alyssa Coghlan am 17. Februar 2013 angenommen.

Begründung

Heute generiert „python setup.py bdist“ auf PyPy und CPython denselben Dateinamen, aber ein inkompatibles Archiv, was den Austausch kompilierter Distributionen im selben Ordner oder Index unbequem macht. Stattdessen sollten kompilierte Distributionen eine Dateinamenskonvention haben, die genügend Informationen enthält, um zu entscheiden, ob ein bestimmtes Archiv mit einer bestimmten Implementierung kompatibel ist oder nicht.

Frühere Bemühungen stammen aus einer Zeit, in der CPython die einzige wichtige Implementierung war und die ABI mit der Python-Sprachversion identisch war. Diese Spezifikation verbessert die älteren Schemata, indem sie die Python-Implementierung, Sprachversion, ABI und Plattform als eine Reihe von Tags enthält.

Durch den Vergleich der von ihm unterstützten Tags mit den von der Distribution aufgeführten Tags kann ein Installer eine fundierte Entscheidung treffen, ob er eine bestimmte kompilierte Distribution herunterladen soll, ohne ihre vollständigen Metadaten lesen zu müssen.

Übersicht

Das Tag-Format ist {Python-Tag}-{ABI-Tag}-{Plattform-Tag}

Python-Tag

„py27“, „cp33“

abi tag

„cp32dmu“, „none“

platform tag

„linux_x86_64“, „any“

Zum Beispiel ist der Tag py27-none-any kompatibel mit Python 2.7 (jeder Python 2.7-Implementierung) ohne ABI-Anforderung, auf jeder Plattform.

Verwendung

Das kompilierte Paketformat wheel enthält diese Tags in seinen Dateinamen im Format {distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl. Andere Paketformate können ihre eigenen Konventionen haben.

Details

Verwendung

Die Tags werden von Installern verwendet, um zu entscheiden, welche kompilierte Distribution (falls vorhanden) aus einer Liste potenzieller kompilierter Distributionen heruntergeladen werden soll. Der Installer unterhält eine Liste von (pyver, abi, arch)-Tupeln, die er unterstützt. Wenn der Tag der kompilierten Distribution in der Liste ist, kann sie installiert werden.

Es wird empfohlen, dass Installer standardmäßig versuchen, die am vollständigsten funktionierende kompilierte Distribution (diejenige, die am spezifischsten für die Installationsumgebung ist) auszuwählen, bevor sie auf reine Python-Versionen zurückfallen, die für ältere Python-Releases veröffentlicht wurden. Es wird auch empfohlen, dass Installer eine Möglichkeit bieten, die Liste der zulässigen Kompatibilitätstags zu konfigurieren und neu zu ordnen; zum Beispiel könnte ein Benutzer nur die *-none-any-Tags akzeptieren, um nur vorkompilierte Pakete herunterzuladen, die sich als reine Python-Pakete ausgeben.

Eine weitere wünschenswerte Installerfunktion könnte sein, „bei Möglichkeit aus dem Quellcode neu kompilieren“ einzuschließen, da dies einigen kompatiblen, aber älteren vorkompilierten Optionen vorgezogen wird.

Diese Beispiel-Liste gilt für einen Installer, der unter CPython 3.3 auf einem linux_x86_64-System läuft. Sie ist geordnet von der am meisten bevorzugten (eine Distribution mit einem kompilierten Erweiterungsmodul, gebaut für die aktuelle Version von Python) zur am wenigsten bevorzugten (eine reine Python-Distribution, gebaut mit einer älteren Version von Python).

1. cp33-cp33m-linux_x86_64
2. cp33-abi3-linux_x86_64
3. cp3-abi3-linux_x86_64
4. cp33-none-linux_x86_64*
5. cp3-none-linux_x86_64*
6. py33-none-linux_x86_64*
7. py3-none-linux_x86_64*
8. cp33-none-any
9. cp3-none-any
10. py33-none-any
11. py3-none-any
12. py32-none-any
13. py31-none-any
14. py30-none-any

• Kompilierte Distributionen können aus anderen Gründen als C-Erweiterungen plattformspezifisch sein, z. B. indem sie eine native ausführbare Datei enthalten, die als Subprozess aufgerufen wird.

Manchmal gibt es mehr als eine unterstützte kompilierte Distribution für eine bestimmte Version eines Pakets. Zum Beispiel könnte ein Packager ein Paket veröffentlichen, das mit cp33-abi3-linux_x86_64 getaggt ist und eine optionale C-Erweiterung enthält, und dieselbe Distribution, die mit py3-none-any getaggt ist und keine enthält. Der Index des Tags in der Liste der unterstützten Tags bricht das Gleichgewicht, und das Paket mit der C-Erweiterung wird gegenüber dem Paket ohne installiert, da dieser Tag zuerst in der Liste erscheint.

Komprimierte Tag-Sätze

Um kompakte Dateinamen für bdists zu ermöglichen, die mit mehr als einem Kompatibilitätstag-Triple funktionieren, kann jeder Tag in einem Dateinamen stattdessen ein durch Punkte . getrennter, sortierter Satz von Tags sein. Zum Beispiel könnte pip, ein reines Python-Paket, das für die Ausführung unter Python 2 und 3 mit demselben Quellcode geschrieben ist, eine bdist mit dem Tag py2.py3-none-any verteilen. Die vollständige Liste der einfachen Tags ist

for x in pytag.split('.'):
    for y in abitag.split('.'):
        for z in archtag.split('.'):
            yield '-'.join((x, y, z))

Ein bdist-Format, das dieses Schema implementiert, sollte die erweiterten Tags in bdist-spezifischen Metadaten enthalten. Dieses Komprimierungsschema kann eine große Anzahl von nicht unterstützten Tags und „unmöglichen“ Tags generieren, die von keiner Python-Implementierung unterstützt werden, z. B. „cp33-cp31u-win64“, also verwenden Sie es sparsam.

FAQ

Welche Tags werden standardmäßig verwendet?

Tools sollten standardmäßig den am meisten bevorzugten architekturabhängigen Tag, z. B. cp33-cp33m-win32, oder den am meisten bevorzugten reinen Python-Tag, z. B. py33-none-any, verwenden. Wenn der Packager den Standard überschreibt, bedeutet dies, dass er beabsichtigt hat, plattformübergreifende Python-Kompatibilität zu bieten.

Welchen Tag soll ich verwenden, wenn meine Distribution eine Funktion verwendet, die exklusiv für die neueste Version von Python ist?

Kompatibilitätstags helfen Installern bei der Auswahl des *kompatibelsten* Builds einer *einzelnen Version* einer Distribution. Wenn es beispielsweise keinen Python 3.3-kompatiblen Build von beaglevote-1.2.0 gibt (er verwendet eine für Python 3.4 exklusive Funktion), kann er immer noch den py3-none-any-Tag anstelle des py34-none-any-Tags verwenden. Ein Python 3.3-Benutzer muss andere Qualifizierer kombinieren, wie z. B. eine Anforderung für die ältere Version beaglevote-1.1.0, die die neue Funktion nicht verwendet, um einen kompatiblen Build zu erhalten.

Warum gibt es keine . in der Python-Versionsnummer?

CPython hat über 20 Jahre ohne eine 3-stellige Hauptveröffentlichung überdauert. Dies sollte noch einige Zeit so bleiben. Andere Implementierungen können den Unterstrich als Trennzeichen verwenden, da sowohl Bindestrich als auch Punkt die umliegenden Dateinamen trennen.

Warum Bindestriche und andere nicht-alphanumerische Zeichen in Unterstriche normalisieren?

Um Konflikte mit den Zeichen „.“ und „-„ zu vermeiden, die Komponenten des Dateinamens trennen, und für eine bessere Kompatibilität mit einer breiteren Palette von Dateisystembeschränkungen für Dateinamen (einschließlich der Verwendbarkeit in URL-Pfaden ohne Anführungszeichen).

Warum nicht das Sonderzeichen <X> anstelle von „.“ oder „-„ verwenden?

Entweder weil dieses Zeichen in einigen Kontexten unbequem oder potenziell verwirrend ist (z. B. „+“ muss in URLs in Anführungszeichen gesetzt werden, „~“ wird verwendet, um das Home-Verzeichnis des Benutzers unter POSIX zu bezeichnen) oder weil die Vorteile nicht überzeugend genug waren, um die Änderung der bestehenden Referenzimplementierung für das in PEP 427 definierte Wheel-Format zu rechtfertigen (z. B. Verwendung von „,“ anstelle von „.“ zur Trennung von Komponenten in einem komprimierten Tag).

Wer wird das Register der abgekürzten Implementierungen pflegen?

Neue Zwei-Buchstaben-Abkürzungen können auf der python-dev Mailingliste angefordert werden. Als Faustregel gelten Abkürzungen für die derzeit 4 prominentesten Implementierungen.

Wird der Kompatibilitätstag in METADATA oder PKG-INFO aufgenommen?

Nein. Der Kompatibilitätstag ist Teil der Metadaten der kompilierten Distribution. METADATA / PKG-INFO sollten für eine gesamte Distribution gültig sein, nicht für einen einzelnen Build dieser Distribution.

Warum hast du meine bevorzugte Python-Implementierung nicht erwähnt?

Die abgekürzten Tags erleichtern den Austausch kompilierter Python-Codes in einem öffentlichen Index. Ihre Python-Implementierung kann diese Spezifikation ebenfalls verwenden, jedoch mit längeren Tags. Denken Sie daran, dass alle „reinen Python“-kompilierten Distributionen nur „py“ verwenden.

Warum ist der ABI-Tag (der zweite Tag) in der Referenzimplementierung manchmal „none“?

Da Python 2 keine einfache Möglichkeit bietet, an die SOABI zu gelangen (das Konzept stammt aus neueren Versionen von Python 3), schätzt die Referenzimplementierung zum Zeitpunkt des Schreibens „none“. Idealerweise würde sie „py27(d|m|u)“ analog zu neueren Versionen von Python erkennen, aber in der Zwischenzeit ist „none“ eine gute genug Möglichkeit, um zu sagen „weiß nicht“.

Referenzen

[1] Egg-Dateinamen-eingebettete Metadaten (http://peak.telecommunity.com/DevCenter/EggFormats#filename-embedded-metadata)

[2] Kompilierte Distributionen erstellen (https://docs.pythonlang.de/3.4/distutils/builtdist.html)

Danksagungen

Der Autor dankt Paul Moore, Alyssa Coghlan, Marc Abramowitz und Herrn Michele Lacchia für ihre wertvolle Hilfe und Beratung.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.