Zusammenfassung

Die Paketauflösung ist ein Schlüsselbestandteil der Python-Benutzererfahrung, da sie die Mittel zur Erweiterung der Kernfunktionalität von Python darstellt. Das Erlebnis der Paketauflösung wird meist als selbstverständlich hingenommen, bis jemand auf eine Situation stößt, in der der Paketinstaller etwas tut, was er nicht erwartet. Das Verhalten des Installers bei mehreren Indizes war eine häufige Quelle für unerwartetes Verhalten. Durch seine Allgegenwart hat pip lange Zeit das erwartete Standardverhalten für andere Tools im Ökosystem definiert, aber Python-Installer divergieren in Bezug darauf, wie sie mehrere Indizes handhaben. Im Kern dieser Divergenz steht die Frage, ob die Indexinhalte vor der Auflösung von Distributionen kombiniert werden oder ob jeder Index einzeln in Reihenfolge behandelt wird. pip kombiniert alle Indizes, bevor es Distributionen abgleicht, während uv Distributionen in einem Index abgleicht, bevor es zum nächsten übergeht. Jeder Ansatz hat Vor- und Nachteile. Dieses PEP zielt darauf ab, jedes dieser Verhaltensweisen zu beschreiben, die als „Version Priorität“ bzw. „Index Priorität“ bezeichnet werden, damit Community-Diskussionen und Fehlerbehebungen einen gemeinsamen Wortschatz teilen können und damit Tools vorhersagbares Verhalten auf der Grundlage dieser Beschreibungen implementieren können.

Motivation

Python-Paketnutzer finden sich häufig in der Notwendigkeit wieder, einen Index oder eine Paketquelle anzugeben, die sich von PyPI unterscheidet. Es gibt viele Gründe für die Existenz externer Indizes

• Dateigrößen-/Kontingentbeschränkungen auf PyPI
• Implementierungsvarianten, wie z. B. verschiedene Builds von GPU-Bibliotheken in PyTorch
• Lokale Builds von Paketen, die intern in einer Organisation geteilt werden
• Situationen, in denen ein lokales Paket entfernte Abhängigkeiten hat und der Benutzer lokale Pakete gegenüber entfernten Abhängigkeiten bevorzugen möchte, während er bei Bedarf weiterhin auf entfernte Abhängigkeiten zurückfällt

In den meisten dieser Fälle ist es nicht wünschenswert, PyPI vollständig zu umgehen. Stattdessen möchten Benutzer im Allgemeinen, dass PyPI weiterhin eine Quelle für Pakete ist, aber eine Quelle mit niedrigerer Priorität. Leider schließt das aktuelle Design von pip dieses Konzept der Priorität aus. Einige Python-Installer-Tools haben alternative Wege zur Handhabung mehrerer Indizes entwickelt, die Mechanismen zur Ausdruck von Indexpriorität beinhalten, wie z. B. uv und PDM.

Die Innovation und das Potenzial für Anpassung sind spannend, aber sie bergen das Risiko einer weiteren Fragmentierung des Python-Paket-Ökosystems, das bereits als einer der Schwachpunkte von Python wahrgenommen wird. Die Motivation dieses PEP ist es, Installer zu ermutigen, mehr Einblick in die Art und Weise zu geben, wie sie mehrere Indizes handhaben, und einen gemeinsamen Wortschatz für die breitere Community bereitzustellen.

Spezifikation

Abwärtskompatibilität

Dieses PEP schreibt keine Änderungen als obligatorisch für irgendeinen Installer vor, daher führt es nur zu Kompatibilitätsproblemen, wenn Tools ein Index-Verhalten wählen, das sich von dem unterscheidet, das sie derzeit implementieren.

Die Sprache dieses PEP stimmt nicht ganz mit bestehenden Tools, einschließlich pip und uv, überein. Entweder kann die Sprache dieses PEP während der Überprüfung dieses PEP geändert werden, oder wenn die Sprache dieses PEP bevorzugt wird, könnten andere Projekte sie übernehmen. Das einzige Ziel der vorgeschlagenen Begriffe ist die Schaffung eines zentralen, gemeinsamen Wortschatzes, der es Benutzern erleichtert, sich über andere Installer zu informieren.

Da einige Tools auf das eine oder andere Verhalten angewiesen sind, können einige Probleme auftreten, bei denen die Anpassung verfügbarer Ressourcen/Pakete für ein bestimmtes Verhalten die Benutzererfahrung für Personen beeinträchtigen kann, die sich auf das andere Verhalten verlassen.

• Unterschiedliche Indizes können unterschiedliche Metadaten haben. Man kann zum Beispiel nicht davon ausgehen, dass die Metadaten für das Paket „something“ im Index „A“ dieselben Abhängigkeiten haben wie „something“ im Index „B“. Dies bricht grundlegende Annahmen der Version Priorität, aber Index Priorität kann damit umgehen. Wenn ein Installer im Suchverlauf zu einem Index mit niedrigerer Priorität durchfällt, impliziert dies die Aktualisierung der Paketmetadaten aus dem neuen Index. Dies ist sowohl eine Verbesserung als auch eine Komplikation. Es ist eine Komplikation in dem Sinne, dass ein gecachter Metadateneintrag sowohl nach Paketname als auch nach Index-URL indiziert werden muss, anstatt nur nach Paketname. Es ist eine potenzielle Verbesserung, da verschiedene Implementierungsvarianten eines Pakets in den Abhängigkeiten unterschiedlich sein können, solange ihre Distributionen in verschiedene Indizes aufgeteilt sind.
• Benutzer erhalten möglicherweise nicht die erwarteten Updates bei Verwendung von Index Priorität, da ein höher priorisierter Index nicht mit PyPI aktualisiert/synchronisiert wurde, um die neuesten Pakete zu erhalten. Wenn der höher priorisierte Index einen gültigen Kandidaten hat, werden neuere Pakete nicht gefunden. Dies muss sehr ausführlich kommuniziert werden, da es dem gut etablierten Verhalten von pip widerspricht.
• Durch die Hinzufügung von Index Priorität verbessert ein Installer die Vorhersagbarkeit, welcher Index ausgewählt wird, und Index-Hosts können dies missbrauchen, indem sie ähnlich benannte Dateien mit unterschiedlichen Inhalten anbieten. Bei Version Priorität verletzt dies die entscheidende Annahme der Paket-Austauschbarkeit, und Wahnsinn wird folgen. Index Priorität wäre praktikabler, aber die Situation birgt immer noch großes Potenzial für Verwirrung. Es wäre hilfreich, Werkzeuge zu entwickeln, die Installer bei der Identifizierung dieser verwirrenden Probleme unterstützen. Diese Werkzeuge könnten unabhängig vom Installer-Prozess betrieben werden, um die Sinnhaftigkeit eines Satzes von Indizes zu validieren. Abhängig von der Zeitkosten dieser Werkzeuge könnten die Installer sie als Teil ihres Prozesses ausführen. Benutzer könnten die Empfehlungen natürlich auf eigene Gefahr ignorieren.

Sicherheitsimplikationen

Index Priorität schafft einen Mechanismus, mit dem Benutzer explizit eine Vertrauenshierarchie unter ihren Indizes angeben können. Als solche schränkt sie das Potenzial für Dependency-Confusion-Angriffe ein. Index Priorität wurde von PEP 708 als Lösung für Dependency-Confusion-Angriffe abgelehnt. Dieses PEP bittet darum, dass die Ablehnung überdacht wird, wobei Index Priorität einen anderen Zweck erfüllt. Dieses PEP wird hauptsächlich durch den Wunsch motiviert, Implementierungsvarianten zu unterstützen, was das Thema einer weiteren Diskussion ist, die hoffentlich zu einem PEP führt. Es ist nicht gegenseitig ausschließend mit PEP 708 und schlägt auch nicht vor, PEP 708 rückgängig zu machen oder zurückzuziehen. Es ist eine Antwort auf die Frage, wie Benutzer wählen können, welchen Index sie auf einer feingranulareren Ebene als „pro Installation“ verwenden möchten.

Für eine gründlichere Diskussion der Ablehnung der Index Priorität durch PEP 708 siehe den Diskussionsfaden auf discuss.python.org für dieses PEP.

Wie man das lehrt

Zu Beginn ist es nicht das Ziel, pip oder ein anderes Tool dazu zu bewegen, sein Standard-Prioritätsverhalten zu ändern. Der beste Weg zu lehren ist vielleicht, Nachrichtenforen, GitHub-Issue-Tracker und Chat-Kanäle zu beobachten und nach Problemen Ausschau zu halten, bei deren Lösung Index Priorität helfen könnte. Es gibt mehrere langjährige Diskussionen darüber wäre eine gute Ausgangsbasis, um die Konzepte zu bewerben. Die Themen der beiden offiziell unterstützten Verhaltensweisen müssen dokumentiert werden, und wir, die Autoren dieses PEP, würden diese während der Überprüfungsphase dieses PEP entwickeln. Diese Dokumentation würde wahrscheinlich Ergänzungen über mehrere Indizes umfassen, die die Konzepte zwischen den Installern verknüpfen. Mindestens erwarten wir, die PyPUG und die pip-Dokumentation zu ergänzen.

Es wird für Installer wichtig sein, das aktive Verhalten zu bewerben, insbesondere in Fehlermeldungen, und dies wird Möglichkeiten bieten, Benutzern Ressourcen zu diesen Verhaltensweisen zur Verfügung zu stellen.

uv-Benutzer erleben bereits Index Priorität. uv dokumentiert dieses Verhalten gut, aber es ist immer möglich, die Auffindbarkeit dieser Dokumentation über die Befehlszeile zu verbessern, wo Benutzer auf das unerwartete Verhalten stoßen werden.

Referenzimplementierung

Das uv-Projekt demonstriert Index Priorität mit seinem Standardverhalten. uv ist jedoch in Rust implementiert. Wenn eine Referenzimplementierung für ein Python-basiertes Tool erforderlich ist, werden wir, die Autoren dieses PEP, eine solche bereitstellen. Insbesondere für pip sehen wir den Implementierungsplan wie folgt

• Für Benutzer, die --extra-index-url oder --find-links nicht verwenden, wird es keine Änderung geben und keine Migration erforderlich sein.
• pip-Benutzer könnten sich über eine neue Konfigurationseinstellung in der CLI und in pip.conf für das Index-Prioritätsverhalten entscheiden. Dieser Vorschlag empfiehlt keine Strategie als Standard für irgendeinen Installer. Er empfiehlt nur die Dokumentation der Strategien, die ein Tool bereitstellt.
• Zusätzliche Info-Level-Ausgabe für jede pip-Operation, bei der mehr als ein Index verwendet wird. In dieser Ausgabe geben Sie die aktuelle Strategie-Einstellung und eine knappe Zusammenfassung des impliziten Verhaltens sowie einen Link zu Dokumenten, die die verschiedenen Optionen beschreiben, an.
• Fügen Sie Debugging-Ausgaben hinzu, die den verwendeten Index bei jedem Schritt ausführlich identifizieren, einschließlich der Position der Datei in der Konfigurationshierarchie und wo sie einbezogen wird (über Konfigurationsdatei, Umgebungsvariable oder CLI-Flag).
• Verfolgen Sie die Weitergabe des verwendeten Index für jedes Paket/jede Distribution während des gesamten pip install-Prozesses. Speichern Sie diese Informationen, damit sie für Tools wie pip freeze verfügbar sind.
• Ergänzen Sie PEP 751 (Lockfiles) um die Erfassung des Index, von dem ein Paket/eine Distribution stammt.

Abgelehnte Ideen

• Weisen Sie Benutzer an, einen Proxy/Mirror einzurichten, wie z. B. devpi oder Artifactory, der lokale Dateien bereitstellt, falls vorhanden, und an einen anderen Server (PyPI) weiterleitet, wenn keine lokalen Dateien übereinstimmen.

  Dies entspricht dem Verhalten dieses Vorschlags sehr genau, außer dass diese Methode das Hosten eines Servers erfordert und für Benutzer in einigen Umgebungen unzugänglich oder nicht konfigurierbar sein kann. Es ist auch wichtig zu bedenken, dass für eine Organisation, die ihren eigenen Index betreibt (z. B. zur Überwindung von PyPI-Größenbeschränkungen), dies nicht die Notwendigkeit von --extra-index-url oder Proxy/Mirror für Endbenutzer löst. Das heißt, Organisationen erhalten keine Verbesserung durch diesen Ansatz, es sei denn, sie leiten PyPI als Ganzes über einen Proxy/Mirror und veranlassen Benutzer, ihren Proxy/Mirror als einzigen Index zu konfigurieren.

• Sind Build-Tags und/oder lokale Versionsspezifizierer ausreichend?

  Build-Tags und lokale Versionsspezifizierer haben Vorrang vor Paketen ohne diese Tags und/oder lokalen Versionsspezifizierer. In einem Pool von Paketen haben Builds, die diese Ergänzungen auf einem anderen Server als PyPI gehostet haben, Vorrang vor Paketen auf PyPI, die selten Build-Tags verwenden und lokale Versionsspezifizierer verbieten. Dieser Ansatz ist machbar, wenn Paket-Anbieter ihre eigenen lokalen Überschreibungen bereitstellen möchten, wie z. B. HPC-Maintainer, die optimierte Builds für ihre Benutzer bereitstellen. Er ist in gewisser Weise weniger praktikabel, da Build-Tags nicht in den Metadaten von pip freeze angezeigt werden und lokale Versionsspezifizierer auf PyPI nicht zulässig sind. Zudem ist der Aufbau und die Wartung von Paketsammlungen mit lokalen Build-Tag-Varianten mit erheblichem Aufwand verbunden.

  https://discuss.python.org/t/dependency-notation-including-the-index-url/5659/21

• Was ist mit PEP 708? Ist das nicht genug?

  PEP 708 zielt speziell darauf ab, Dependency-Confusion-Angriffe zu bekämpfen, und befasst sich nicht mit dem Potenzial für Implementierungsvarianten zwischen Indizes. Es ist eine Möglichkeit, externe URLs zu filtern und eine Whitelist für externe Indizes in Index-Metadaten zu kodieren. Es ändert nichts am derzeitigen Mangel an Priorität oder Präferenz zwischen Kanälen.

• Namespacing

  Namespacing ist ein Mittel zur Spezifizierung eines Pakets, so dass die Python-Nutzung des Pakets unverändert bleibt, die Paketinstallation aber einschränkt, woher das Paket stammt. PEP 752 schlug kürzlich eine Möglichkeit vor, die Besitzer eines Pakets in einem flachen Paket-Namespace (z. B. PyPI) zu multiplexen, indem Präfixe als Gruppierungselemente reserviert werden. Das Konzept der „Scopes“ von NPM wurde als weiteres gutes Beispiel dafür genannt, wie dies aussehen könnte. Dieses PEP unterscheidet sich dadurch, dass es sich auf mehrere Indizes konzentriert und nicht auf einen flachen Paket-Namespace. Der Nettoeffekt ist in Bezug auf die vorhersagbare Auswahl einer bestimmten Paketquelle ungefähr derselbe, außer dass der Namespacing-Ansatz mehr auf der Benennung von Paketen mit diesen Namespace-Präfixen basiert, während dieses PEP weniger granular wäre und Pakete aus dem höher priorisierten Index zieht, den der Benutzer angibt. Der Namespacing-Ansatz setzt voraus, dass alle konfigurierten Indizes einen gegebenen Namespace ähnlich behandeln, was zu der üblichen Sorge führt, dass nicht alle konfigurierten Indizes gleichermaßen vertrauenswürdig sind. Die Namespace-Idee ist mit diesem PEP nicht unvereinbar, verbessert aber auch nicht die Ausdruck von Vertrauen in Indizes, wie es dieses PEP tut.

Offene Fragen

[Alle Punkte, die noch entschieden/diskutiert werden.]

Danksagungen

Diese Arbeit wurde finanziell von NVIDIA durch die Anstellung des Autors unterstützt. NVIDIA-Kollegen haben dieses PEP mit ihren Beiträgen dramatisch verbessert. Astral Software hat die Verhaltensweisen der Index-Priorität pionierhaft entwickelt und damit die Grundlage dieses Dokuments gelegt. Den pip-Autoren gebührt großes Lob für ihre konsequente Richtung und geduldige Kommunikation des Version-Prioritätsverhaltens, insbesondere angesichts kontroverser Sicherheitsbedenken.

Urheberrecht

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