Dateiformate

Derzeit unterstützt PyPI die folgenden Dateitypen

• sdist
• bdist_wheel
• bdist_egg
• bdist_wininst
• bdist_msi
• bdist_dmg
• bdist_rpm
• bdist_dumb

Diese verschiedenen Dateitypen haben jedoch unterschiedliche Nützlichkeitsgrade oder allgemeine Verwendung im Ökosystem. Ihre fortgesetzte Unterstützung verursacht einen Wartungsaufwand für PyPI sowie für Tool-Autoren und verursacht Kosten sowohl für Bandbreite als auch für Speicherplatz, nicht nur auf PyPI selbst, sondern auch auf allen Spiegelservern von PyPI.

Python-Packaging ist ein mehrstufiges Ökosystem, in dem PyPI hauptsächlich zur Verteilung von virtuellen Umgebung-kompatiblen Paketen direkt von den jeweiligen Projektbesitzern geeignet und genutzt wird. Diese Pakete werden dann entweder direkt von Endbenutzern oder von nachgelagerten Verteiler*innen konsumiert, die diese Pakete nehmen und sie in ihre jeweiligen systemweiten Pakete (wie RPM, deb, MSI usw.) umwandeln.

Während PyPI selbst nur direkt mit diesen plattformunabhängigen, aber Python-spezifischen Paketen arbeitet, fördern wir gemeinschaftsgetriebene und kommerzielle Konvertierungen dieser Pakete in nachgelagerte Formate für bestimmte Zielumgebungen, wie zum Beispiel:

• Das plattformübergreifende Datenanalyse-Ökosystem von Conda (conda-forge)
• Das deb-basierte Linux-Ökosystem (Debian, Ubuntu usw.)
• Das RPM-basierte Linux-Ökosystem (Fedora, openSuSE, Mageia usw.)
• Die Ökosysteme Homebrew, MacPorts und Fink für Mac OS X
• Das Windows-Paketmanagement-Ökosystem (NuGet, Chocolatey usw.)
• Erstellung von Windows MSIs und Installern durch Dritte (z. B. Christoph Gohlkes Arbeit unter http://www.lfd.uci.edu/~gohlke/pythonlibs/)
• Andere kommerzielle Weiterverteilungsformate (ActiveStates PyPM, Enthought Canopy usw.)
• Andere Open-Source-Community-Weiterverteilungsformate (Nix, Gentoo, Arch, *BSD usw.)

Die Überzeugung dieses PEP ist, dass das gesamte Ökosystem am besten unterstützt wird, indem PyPI auf die plattformunabhängigen Formate konzentriert bleibt, wo die begrenzte Zeit von Freiwilligen am besten genutzt werden kann, anstatt die verfügbare Zeit auf mehrere Plattformen zu verteilen. Darüber hinaus ist dieser PEP der Meinung, dass die Personen, die am besten positioniert sind, gut integrierte Pakete für eine bestimmte Plattform bereitzustellen, diejenigen sind, die sich auf diese Plattform konzentrieren und nicht auf alle möglichen Plattformen.

Dateierweiterungen

Derzeit unterstützt sdist eine Vielzahl von Dateierweiterungen wie .tar.gz, .tar, .tar.bz2, .tar.xz, .zip, .tar.Z, .tgz und .tbz. Von diesen erhalten jedoch nur die Erweiterungen .tar.gz mit derzeit 444.338 sdists, .zip mit derzeit 58.774 sdists und .tar.bz2 mit derzeit 3.265 sdists mehr als nur vernachlässigbare Nutzung.

Das Vorhandensein mehrerer akzeptierter Formate erfordert, dass sowohl PyPI als auch externe Tools alle verschiedenen Erweiterungen behandeln können, die verwendet *werden könnten* (auch wenn niemand sie derzeit verwendet). Dies betrifft nicht nur PyPI, sondern wirkt sich auf das gesamte Ökosystem aus. Darüber hinaus haben die verschiedenen Formate unterschiedliche Anforderungen an optionale C-Bibliotheken, mit denen Python verknüpft wurde, und unterschiedliche Anforderungen an die Python-Versionen, die sie unterstützen. Außerdem schaffen mehrere Formate eine seltsame Situation, in der es zwei sdist-Dateien für ein bestimmtes Projekt/eine bestimmte Version mit subtil unterschiedlichem Inhalt geben kann.

Es ist leicht zu argumentieren, dass alles außerhalb von .tar.gz, .zip und .tar.bz2 verboten werden sollte. Abgesehen von einer winzigen Handvoll hat niemand diese anderen Dateitypen in den rund 15 Jahren der Existenz von PyPI aktiv hochgeladen, daher waren sie offensichtlich nicht besonders nützlich. Obwohl .tar.xz theoretisch ein besseres Format als die anderen .tar.*-Formate ist, da es eine bessere Kompressionsrate mit LZMA erzielt, ist es nur in Python 3.3+ verfügbar und hat eine optionale Abhängigkeit von der lzma-C-Bibliothek.

Betrachtet man die drei Erweiterungen, die wir derzeit verwenden, ist es auch recht einfach zu dem Schluss zu kommen, dass .tar.bz2 ebenfalls verboten werden kann. Es gibt eine ziemlich kleine Anzahl von Dateien, die jemals damit hochgeladen wurden, und es erfordert eine zusätzliche optionale C-Bibliothek zur Handhabung der bzip2-Kompression.

Schließlich landen wir bei .tar.gz und .zip. Betrachtet man die reinen Zahlen für diese beiden, sehen wir, dass .tar.gz mit insgesamt 444.338 Uploads das mit Abstand am häufigsten hochgeladene Format ist, verglichen mit 58.774 von .zip. Auf POSIX-Betriebssystemen ist .tar.gz auch der Standard, der von allen aktuell veröffentlichten Versionen von Python und setuptools erzeugt wird. Darüber hinaus verwenden beide Dateitypen dieselbe C-Bibliothek (zlib), die auch für bdist_wheel und bdist_egg erforderlich ist. Die beiden kniffligen Punkte bei der Entscheidung zwischen .tar.gz und .zip sind, dass auf POSIX-Betriebssystemen .tar.gz der Standard ist, während unter Windows .zip der Standard ist und das bdist_wheel-Format ebenfalls Zip verwendet.

Anstatt zu versuchen, sich entweder auf .tar.gz oder .zip zu standardisieren, schlägt dieser PEP vor, dass wir *entweder* .tar.gz *oder* .zip für sdists zulassen.

Beschränkung der Anzahl von sdists pro Release

Ein sdist auf PyPI sollte eine einzige Quelle der Wahrheit für eine bestimmte Softwareversion sein. Derzeit erlaubt PyPI jedoch den Upload eines sdists für jede der erlaubten sdist-Dateierweiterungen. Derzeit sind dies etwa 10 verschiedene sdists für ein Projekt, aber selbst mit diesem PEP erlaubt dies zwei verschiedene Wahrheitsquellen für eine einzelne Version. Das Vorhandensein mehrerer sdists kann oft seltsame Fehler erklären, die sich nur dadurch äußern, welcher sdist von der Person verwendet wurde.

Um dies zu beheben, schlägt dieser PEP vor, einen und nur einen sdist pro Release eines Projekts zuzulassen.