Installation eines Wheels 'distribution-1.0-py32-none-any.whl'

Die Wheel-Installation besteht notionsweise aus zwei Phasen

• Entpacken.
  1. Parsen von distribution-1.0.dist-info/WHEEL.
  2. Prüfen, ob der Installer mit Wheel-Version kompatibel ist. Warnen, wenn die Nebenversion größer ist, abbrechen, wenn die Hauptversion größer ist.
  3. Wenn Root-Is-Purelib == 'true', das Archiv in purelib (site-packages) entpacken.
  4. Andernfalls das Archiv in platlib (site-packages) entpacken.
• Verteilung.
  1. Das entpackte Archiv enthält distribution-1.0.dist-info/ und (falls vorhanden) distribution-1.0.data/.
  2. Verschieben jedes Unterverzeichnisses von distribution-1.0.data/ auf seinen Zielpfad. Jedes Unterverzeichnis von distribution-1.0.data/ ist ein Schlüssel in einem Wörterbuch von Zielverzeichnissen, wie z. B. distribution-1.0.data/(purelib|platlib|headers|scripts|data).
  3. Skripte, die mit #!python beginnen, aktualisieren, um auf den richtigen Interpreter zu verweisen. (Hinweis: Python-Skripte werden normalerweise über Paketmetadaten behandelt und nicht wortwörtlich in Wheel enthalten.)
  4. Aktualisieren von distribution-1.0.dist.info/RECORD mit den installierten Pfaden.
  5. Wenn leer, das Verzeichnis distribution-1.0.data entfernen.
  6. Kompilieren aller installierten .py zu .pyc. (Deinstallierer sollten intelligent genug sein, .pyc zu entfernen, auch wenn es nicht in RECORD aufgeführt ist.)

In der Praxis werden Installer normalerweise Dateien direkt aus dem Archiv an ihre Ziele extrahieren, ohne ein temporäres Verzeichnis distribution-1.0.data/ zu erstellen.

Dateiformat

re.sub("[^\w\d.]+", "_", distribution, re.UNICODE)

distribution-1.0.dist-info/

distribution-1.0.data/

{
    'bindir': '$eprefix/bin',
    'sbindir': '$eprefix/sbin',
    'libexecdir': '$eprefix/libexec',
    'sysconfdir': '$prefix/etc',
    'sharedstatedir': '$prefix/com',
    'localstatedir': '$prefix/var',
    'libdir': '$eprefix/lib',
    'static_libdir': r'$prefix/lib',
    'includedir': '$prefix/include',
    'datarootdir': '$prefix/share',
    'datadir': '$datarootdir',
    'mandir': '$datarootdir/man',
    'infodir': '$datarootdir/info',
    'localedir': '$datarootdir/locale',
    'docdir': '$datarootdir/doc/$dist_name',
    'htmldir': '$docdir',
    'dvidir': '$docdir',
    'psdir': '$docdir',
    'pdfdir': '$docdir',
    'pkgdatadir': '$datadir/$dist_name'
}

Install-Paths-To: wheel/_paths.py
Install-Paths-To: wheel/_paths.json

data='../wheel-0.26.0.dev1.data/data'
headers='../wheel-0.26.0.dev1.data/headers'
platlib='../wheel-0.26.0.dev1.data/platlib'
purelib='../wheel-0.26.0.dev1.data/purelib'
scripts='../wheel-0.26.0.dev1.data/scripts'
# ...

{ "data": "../wheel-0.26.0.dev1.data/data", ... }

Signierte Wheel-Dateien

Wheel-Dateien enthalten ein erweitertes RECORD, das digitale Signaturen ermöglicht. PEP 376s RECORD wird geändert, um einen sicheren Hash digestname=urlsafe_b64encode_nopad(digest) (urlsafe base64-Kodierung ohne nachfolgende = Zeichen) als zweite Spalte anstelle einer md5sum zu enthalten. Alle möglichen Einträge werden gehasht, einschließlich aller generierten Dateien wie .pyc-Dateien, aber nicht RECORD, das seinen eigenen Hash nicht enthalten kann. Zum Beispiel:

file.py,sha256=AVTFPZpEKzuHr7OvQZmhaU3LvwKz06AJw8mT\_pNh2yI,3144
distribution-1.0.dist-info/RECORD,,

Die Signaturdatei(en) RECORD.jws und RECORD.p7s werden in RECORD überhaupt nicht erwähnt, da sie erst nach der Generierung von RECORD hinzugefügt werden können. Jede andere Datei im Archiv muss einen korrekten Hash in RECORD haben, sonst schlägt die Installation fehl.

Wenn JSON Web Signatures verwendet werden, werden eine oder mehrere JSON Web Signature JSON Serialization (JWS-JS) Signaturen in einer Datei RECORD.jws neben RECORD gespeichert. JWS wird verwendet, um RECORD zu signieren, indem der SHA-256-Hash von RECORD als JSON-Payload der Signatur aufgenommen wird.

{ "hash": "sha256=ADD-r2urObZHcxBW3Cr-vDCu5RJwT4CaRTHiFmbcIYY" }

(Der Hash-Wert ist im gleichen Format wie in RECORD.)

Wenn RECORD.p7s verwendet wird, muss es eine getrennte Signatur von RECORD im S/MIME-Format enthalten.

Ein Wheel-Installer muss zwar keine digitalen Signaturen verstehen, aber er MUSS die Hashes in RECORD gegen die extrahierten Dateiinhalte verifizieren. Wenn der Installer Dateihashes gegen RECORD prüft, muss ein separater Signaturprüfer nur feststellen, dass RECORD mit der Signatur übereinstimmt.

Siehe

• RFC 7515
• https://datatracker.ietf.org/doc/html/draft-jones-jose-jws-json-serialization.html
• RFC 7517
• https://datatracker.ietf.org/doc/html/draft-jones-jose-json-private-key.html

Vergleich zu .egg

1. Wheel ist ein Installationsformat; Egg ist importierbar. Wheel-Archive müssen keine .pyc enthalten und sind weniger an eine bestimmte Python-Version oder Implementierung gebunden. Wheel kann (reine Python-)Pakete installieren, die mit früheren Python-Versionen erstellt wurden, sodass Sie nicht immer auf den Paketierer warten müssen, bis er aufholt.
2. Wheel verwendet .dist-info-Verzeichnisse; Egg verwendet .egg-info. Wheel ist mit der neuen Welt der Python-Paketierung und den neuen Konzepten, die sie mit sich bringt, kompatibel.
3. Wheel hat eine reichhaltigere Dateinamenskonvention für die heutige Multi-Implementierungs-Welt. Ein einzelnes Wheel-Archiv kann seine Kompatibilität mit einer Reihe von Python-Sprachversionen und -Implementierungen, ABIs und Systemarchitekturen angeben. Historisch gesehen war die ABI spezifisch für eine CPython-Version, Wheel ist bereit für die stabile ABI.
4. Wheel ist verlustfrei. Die erste Wheel-Implementierung bdist_wheel generiert immer egg-info und konvertiert es dann in ein .whl. Es ist auch möglich, bestehende Eggs und bdist_wininst-Distributionen zu konvertieren.
5. Wheel ist versioniert. Jede Wheel-Datei enthält die Version der Wheel-Spezifikation und die Implementierung, die sie verpackt hat. Hoffentlich kann die nächste Migration einfach zu Wheel 2.0 erfolgen.
6. Wheel ist eine Referenz auf das andere Python.

Wheel definiert ein .data Verzeichnis. Soll ich all meine Daten dort hineinlegen?

Diese Spezifikation hat keine Meinung dazu, wie Sie Ihren Code organisieren sollen. Das .data-Verzeichnis ist lediglich ein Ort für alle Dateien, die nicht normalerweise innerhalb von site-packages oder auf der PYTHONPATH installiert werden. Mit anderen Worten, Sie können weiterhin pkgutil.get_data(package, resource) verwenden, auch wenn *diese* Dateien normalerweise nicht in Wheels .data-Verzeichnis verteilt werden.

Warum enthält Wheel angehängte Signaturen?

Angehängte Signaturen sind praktischer als getrennte Signaturen, da sie mit dem Archiv reisen. Da nur die einzelnen Dateien signiert werden, kann das Archiv neu komprimiert werden, ohne die Signatur ungültig zu machen, oder einzelne Dateien können verifiziert werden, ohne das gesamte Archiv herunterladen zu müssen.

Warum erlaubt Wheel JWS-Signaturen?

Die JOSE-Spezifikationen, zu denen JWS gehört, sind so konzipiert, dass sie leicht zu implementieren sind, eine Funktion, die auch eines der Hauptentwicklungsziele von Wheel ist. JWS liefert eine nützliche, prägnante reine Python-Implementierung.

Warum erlaubt Wheel auch S/MIME-Signaturen?

S/MIME-Signaturen sind für Benutzer zulässig, die vorhandene Public-Key-Infrastrukturen mit Wheel nutzen müssen oder wollen.

Signierte Pakete sind nur ein grundlegender Baustein in einem sicheren Paket-Update-System. Wheel stellt nur den Baustein bereit.

Was hat es mit "purelib" vs. "platlib" auf sich?

Wheel behält die Unterscheidung "purelib" vs. "platlib" bei, die auf einigen Plattformen wichtig ist. Zum Beispiel installiert Fedora reine Python-Pakete nach '/usr/lib/pythonX.Y/site-packages' und plattformabhängige Pakete nach '/usr/lib64/pythonX.Y/site-packages'.

Ein Wheel mit "Root-Is-Purelib: false" mit allen seinen Dateien in {name}-{version}.data/purelib ist äquivalent zu einem Wheel mit "Root-Is-Purelib: true" mit denselben Dateien im Stammverzeichnis, und es ist zulässig, Dateien sowohl in der "purelib"- als auch in der "platlib"-Kategorie zu haben.

In der Praxis sollte ein Wheel nur eine der beiden Optionen "purelib" oder "platlib" haben, je nachdem, ob es sich um reines Python handelt oder nicht, und diese Dateien sollten sich im Stammverzeichnis befinden, wobei die entsprechende Einstellung für "Root-is-purelib" angegeben ist.

Ist es möglich, Python-Code direkt aus einer Wheel-Datei zu importieren?

Technisch gesehen, aufgrund der Kombination aus Unterstützung der Installation durch einfache Extraktion und der Verwendung eines Archivformats, das mit zipimport kompatibel ist, unterstützt eine Teilmenge von Wheel-Dateien die direkte Platzierung auf sys.path. Allerdings wird die tatsächliche Nutzung dieses Verhaltens, obwohl es eine natürliche Folge des Formatdesigns ist, im Allgemeinen nicht empfohlen.

Erstens ist Wheel *hauptsächlich als Distributionsformat konzipiert*, so dass das Überspringen des Installationsschritts auch bedeutet, bewusst auf Funktionen zu verzichten, die eine vollständige Installation voraussetzen (wie z. B. die Verwendung von Standardwerkzeugen wie pip und virtualenv, um Abhängigkeiten zu erfassen und zu verwalten, die ordnungsgemäß für Prüfungs- und Sicherheitsupdatezwecke nachverfolgt werden können, oder die vollständige Integration mit der Standard-Build-Maschinerie für C-Erweiterungen durch Veröffentlichung von Header-Dateien an der richtigen Stelle).

Zweitens, obwohl einige Python-Software so geschrieben ist, dass sie direkt aus einem ZIP-Archiv ausgeführt werden kann, ist es immer noch üblich, dass Code so geschrieben wird, dass er eine vollständige Installation voraussetzt. Wenn diese Annahme durch den Versuch, die Software aus einem ZIP-Archiv auszuführen, gebrochen wird, können die Fehler oft obskur und schwer zu diagnostizieren sein (insbesondere wenn sie in Drittanbieter-Bibliotheken auftreten). Die beiden häufigsten Problemquellen dabei sind die Tatsache, dass das Importieren von C-Erweiterungen aus einem ZIP-Archiv von CPython *nicht* unterstützt wird (da dies auf keiner Plattform direkt von der dynamischen Ladeinfrastruktur unterstützt wird) und dass bei der Ausführung aus einem ZIP-Archiv das Attribut __file__ nicht mehr auf einen gewöhnlichen Dateisystempfad verweist, sondern auf eine Pfadkombination, die sowohl den Speicherort des ZIP-Archivs im Dateisystem als auch den relativen Pfad zum Modul innerhalb des Archivs umfasst. Selbst wenn Software intern korrekt die abstrakten Ressourcen-APIs verwendet, kann die Schnittstelle mit externen Komponenten immer noch die Verfügbarkeit einer tatsächlichen Datei auf der Festplatte erfordern.

Wie Metaklassen, Monkeypatching und Metapath-Importer: Wenn Sie sich nicht sicher sind, ob Sie diese Funktion nutzen müssen, brauchen Sie sie mit ziemlicher Sicherheit nicht. Wenn Sie sich trotzdem dafür entscheiden, beachten Sie, dass viele Projekte eine Fehlerbehebung benötigen, die mit einem vollständig installierten Paket reproduziert wurde, bevor sie als echter Fehler akzeptiert wird.