Zusammenfassung

Damit ein System für Modul-Repositories (wie Perl's CPAN) erfolgreich ist, muss es für Modulautoren so einfach wie möglich sein, ihre Arbeit einzureichen. Ein offensichtlicher Ort dafür ist das Distutils-Tool nach der erfolgreichen Erstellung des Distributionsarchivs. Nachdem ein Modulautor beispielsweise seine Software getestet hat (und die Ergebnisse von setup.py sdist verifiziert hat), könnte er setup.py sdist --submit eingeben. Dies würde Distutils signalisieren, die Quellcode-Distribution an den Archivserver zu senden, um sie aufzunehmen und an die Mirror zu verteilen.

Dieser PEP befasst sich nur mit dem Mechanismus zum Einreichen von Software-Distributionen beim Archiv und nicht mit dem eigentlichen Archiv/Katalog-Server.

Upload-Prozess

Der Upload wird die Distutils PKG-INFO Metadaten-Informationen (gemäß PEP 241), die eigentliche Software-Distribution und andere optionale Informationen enthalten. Diese Informationen werden als Multi-Part-Formular hochgeladen, das auf die gleiche Weise wie eine reguläre HTML-Datei-Upload-Anfrage kodiert ist. Dieses Formular wird mit der Kodierung ENCTYPE="multipart/form-data" gesendet (RFC 1867).

Der Upload erfolgt an den Host „www.python.org“ auf Port 80/tcp (POST https://pythonlang.de:80/pypi). Das Formular besteht aus den folgenden Feldern

• distribution – Die Datei, die die Modulsoftware enthält (z. B. eine .tar.gz- oder .zip-Datei).
• distmd5sum – Der MD5-Hash der hochgeladenen Distribution, kodiert in ASCII und stellt die hexadezimale Darstellung des Digests dar (for byte in digest: s = s + ('%02x' % ord(byte))).
• pkginfo (optional) – Die Datei, die die Distributionsmetadaten enthält (wie in PEP 241 spezifiziert). Beachten Sie, dass, wenn dies nicht enthalten ist, die Distributionsdatei im .tar-Format (komprimiert mit gzip und bzip2 erlaubt) oder im .zip-Format vorliegen muss, mit einer PKG-INFO-Datei im obersten Verzeichnis, das extrahiert wird (paket-1.00/PKG-INFO).
• infomd5sum (erforderlich, wenn das Feld pkginfo vorhanden ist) – Der MD5-Hash der hochgeladenen Metadaten, kodiert in ASCII und stellt die hexadezimale Darstellung des Digests dar (for byte in digest: s = s + ('%02x' % ord(byte))).
• platform (optional) – Ein String, der die Zielplattform für diese Distribution darstellt. Dies ist nur für Binärdistributionen. Er wird als <os_name>-<os_version>-<platform architecture>-<python version> kodiert.
• signature (optional) – Eine OpenPGP-kompatible Signatur der hochgeladenen Distribution, die vom Autor signiert wurde. Dies kann vom Katalogsystem verwendet werden, um die Annahme von Uploads zu automatisieren.
• protocol_version – Ein String, der die vom Client unterstützte Protokollversion angibt. Dieses Dokument beschreibt die Protokollversion „1“.

Rückgabedaten

Der Status des Uploads wird über HTTP-Nicht-Standard-Header (X-*) gemeldet. Der X-Swalow-Status-Header kann folgende Werte haben

• SUCCESS – Zeigt an, dass der Upload erfolgreich war.
• FAILURE – Der Upload kann aus irgendeinem Grund nicht verarbeitet werden.
• TRYAGAIN – Der Server kann den Upload derzeit nicht akzeptieren, aber der Client sollte es später erneut versuchen. Mögliche Ursachen dafür sind Ressourcenknappheit auf dem Server, administrative Wartungsarbeiten usw.

Optional kann ein X-Swalow-Reason-Header vorhanden sein, der einen menschenlesbaren String enthält, der detailliertere Informationen über den X-Swalow-Status liefert.

Wenn kein X-Swalow-Status-Header vorhanden ist oder dieser keinen der drei oben genannten Strings enthält, sollte dies als vorübergehender Fehler behandelt werden.

Beispiel

>>> f = urllib.urlopen('https://pythonlang.de:80/pypi')
>>> s = f.headers['x-swalow-status']
>>> s = s + ': ' + f.headers.get('x-swalow-reason', '<None>')
>>> print s
FAILURE: Required field "distribution" missing.

Beispielformular

Der Upload-Client muss die Seite in der gleichen Form einreichen, wie Netscape Navigator Version 4.76 für Linux sie erzeugt, wenn ihm das folgende Formular präsentiert wird

<H1>Upload file</H1>
<FORM NAME="fileupload" METHOD="POST" ACTION="pypi"
    ENCTYPE="multipart/form-data">
<INPUT TYPE="file" NAME="distribution"><BR>
<INPUT TYPE="text" NAME="distmd5sum"><BR>
<INPUT TYPE="file" NAME="pkginfo"><BR>
<INPUT TYPE="text" NAME="infomd5sum"><BR>
<INPUT TYPE="text" NAME="platform"><BR>
<INPUT TYPE="text" NAME="signature"><BR>
<INPUT TYPE="hidden" NAME="protocol_version" VALUE="1"><BR>
<INPUT TYPE="SUBMIT" VALUE="Upload">
</FORM>

Plattformen

Die folgenden sind gültige OS-Namen

aix beos debian dos freebsd hpux mac macos mandrake netbsd
openbsd qnx redhat solaris suse windows yellowdog

Oben sind eine Reihe verschiedener Distributionstypen von Linux aufgeführt. Aufgrund von Versionsproblemen müssen diese aufgeteilt werden, und es wird erwartet, dass der Download-Client die Unterscheidung trifft, wenn es für ein System sinnvoll ist, Distributionen zu verwenden, die auf anderen ähnlichen Systemen erstellt wurden.

Version ist die offizielle Versionszeichenkette, die vom Anbieter für die jeweilige Veröffentlichung angegeben wird. Zum Beispiel „2000“ und „nt“ (Windows), „9.04“ (HP-UX), „7.0“ (RedHat, Mandrake).

Die folgenden sind gültige Architekturen

alpha hppa ix86 powerpc sparc ultrasparc

Status

Ich habe derzeit einen Proof-of-Concept-Client und -Server implementiert. Ich plane, die Distutils-Patches für die Veröffentlichung 2.1 bereitzustellen. In Kombination mit Andrew's PEP 241 zur Angabe von Distributionsmetadaten hoffe ich, eine Plattform zu haben, die es uns ermöglicht, reale Daten für die Finalisierung des Katalogsystems für die Veröffentlichung 2.2 zu sammeln.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.