Wichtige Erwartungen an die Benutzererfahrung

1. Externes Hosting soll "einfach funktionieren", wenn es auf System-, Benutzer- oder virtueller Umgebungsebene ordnungsgemäß konfiguriert ist.
2. Alle Referenzen auf die verwirrende Unterscheidung zwischen "verifizierbar extern" und "nicht verifizierbar extern" aus der Benutzererfahrung eliminieren (sowohl bei der Installation als auch bei der Veröffentlichung von Paketen).
3. Die Repository-Aspekte von PyPI sollten *nur* der standardmäßige Paket-Hosting-Standort sein (d.h. der einzige, der von den meisten Client-Tools in ihrer Standardkonfiguration als Opt-out und nicht als Opt-in behandelt wird). Abgesehen davon sollte das Hosting auf PyPI ansonsten keine verbesserte Benutzererfahrung gegenüber dem Hosting eines eigenen Paket-Repositories bieten.
4. Alle oben genannten Punkte umsetzen und gleichzeitig ein Standardverhalten bieten, das gegen die meisten Angreifer unterhalb des staatsfeindlichen Niveaus sicher ist.

Warum zusätzliche Repositories?

Die beiden gängigen Installer-Tools, pip und easy_install/setuptools, unterstützen beide das Konzept von zusätzlichen Speicherorten, um nach Dateien zu suchen, die die Installationsanforderungen erfüllen, und tun dies seit vielen Jahren. Das bedeutet, dass kein neuer Flag oder kein neues Konzept "eingeführt" werden muss und die Lösung zur Installation eines Projekts aus einem anderen Repository als PyPI funktioniert, unabhängig davon, wie alt (im vernünftigen Rahmen) der Installer des Endbenutzers ist. Dieses Konzept existiert nicht nur seit einiger Zeit in den Python-Tools, sondern es ist ein Konzept, das sprachübergreifend und sogar auf Betriebssystemebene mit Betriebssystem-Pakettools existiert, die fast universell die Unterstützung mehrerer Repositories nutzen, was es extrem wahrscheinlich macht, dass jemand bereits mit dem Konzept vertraut ist.

Darüber hinaus ist der Ansatz mit mehreren Repositories ein Konzept, das außerhalb des engen Umfangs der Ermöglichung von Projekten nützlich ist, die im Index-Teil von PyPI enthalten sein sollen, aber nicht den Repository-Teil von PyPI nutzen möchten. Dazu gehören Orte, an denen ein Unternehmen ein Repository hosten möchte, das seine internen Pakete enthält, oder wo ein Projekt mehrere "Kanäle" von Releases haben möchte, wie Alpha, Beta, Release Candidate und finale Release. Dies könnte auch für Projekte verwendet werden, die Dateien hosten möchten, die nicht auf PyPI hochgeladen werden können, wie z. B. Multi-Gigabyte-Datendateien oder derzeit Linux Wheels.

Warum nicht PEP 438 oder Ähnliches?

Während die Unterstützung für zusätzliche Suchorte in pip und setuptools schon seit geraumer Zeit besteht, existiert die Unterstützung für PEP 438 nur in pip seit Version 1.4 und wurde in setuptools noch nicht implementiert. Das Design von PEP 438 bedeutete, dass Benutzer immer noch von Projekten profitierten, die keine externen Dateien benötigten, selbst mit älteren Installern. Für Projekte, die jedoch externe Dateien *benötigten*, erhielten die Benutzer immer noch stillschweigend potenziell unzuverlässige oder, noch schlimmer, unsichere Dateien zum Herunterladen. Dieses System ist auch einzigartig für Python, da es aus der Geschichte von PyPI resultiert. Das bedeutet, dass dieses Konzept für die meisten, wenn nicht alle Benutzer fast sicher fremd sein wird, bis sie es bei der Verwendung der Python-Toolchain antreffen.

Darüber hinaus hat sich das von PEP 438 vorgeschlagene Klassifizierungssystem in der Praxis als extrem verwirrend für Endbenutzer erwiesen, so sehr, dass es die Position dieses PEP ist, dass die Situation, wie sie ist, völlig unhaltbar ist. Das übliche Muster für einen Benutzer mit diesem System ist, zu versuchen, ein Projekt zu installieren, möglicherweise eine Fehlermeldung zu erhalten (oder vielleicht auch nicht, wenn das Projekt jemals etwas auf PyPI hochgeladen hat, dann aber wechselte, ohne alte Dateien zu entfernen), zu sehen, dass die Fehlermeldung `--allow-external` vorschlägt, die Befehlszeile erneut auszuführen und dieses Flag hinzuzufügen, höchstwahrscheinlich eine weitere Fehlermeldung zu erhalten, zu sehen, dass die Fehlermeldung diesmal vorschlägt, auch `--allow-unverified` hinzuzufügen, und die Befehlszeile zum dritten Mal auszuführen, um endlich das zu erhalten, was sie installieren möchten.

Dieses UX-Versagen existiert aus mehreren Gründen.

1. Wenn pip Dateien für ein Projekt über die Simple API finden kann, wird es diese einfach verwenden, anstatt zu versuchen, mehr zu finden. Dies ist im Allgemeinen das Richtige, da der Versuch, mehr zu finden, einen großen Teil des Nutzens von PEP 438 zunichtemachen würde. Das bedeutet, dass, wenn ein Projekt jemals eine Datei hochgeladen hat, die dem vom Benutzer angeforderten Installationsmaterial entspricht, diese verwendet wird, unabhängig davon, wie alt sie ist.
2. PEP 438 geht von der Annahme aus, dass die meisten Projekte sich entweder auf PyPI hochladen oder sich aktualisieren, um direkt auf Release-Dateien zu verlinken. Während sich eine große Anzahl von Projekten letztendlich für den Upload auf PyPI entschied, taten dies einige von ihnen nur, weil die Benutzererfahrung rund um PEP 438 so schlecht war, dass sie sich dazu gezwungen fühlten. Besorgniserregender ist jedoch, dass sich nur sehr wenige Projekte dafür entschieden haben, direkt und sicher auf Dateien zu verlinken, und stattdessen immer noch einfach auf Seiten verlinken, die gescrapt werden müssen, um die eigentlichen Dateien zu finden, wodurch die sichere Variante (`--allow-external`) weitgehend nutzlos wird.
3. Selbst wenn ein Autor direkt auf seine Dateien verlinken möchte, ist dies nicht offensichtlich. Es erfordert die Einbeziehung eines MD5-Hash (aus historischen Gründen) in den Hash der URL. Wenn er diesen nicht einfügt, werden seine Dateien als "nicht verifiziert" betrachtet.
4. PEP 438 verfolgt einen sicherheitszentrierten Ansatz und verbietet jede Form eines globalen Opt-in für nicht verifizierte Projekte. Das ist zwar im Allgemeinen gut, führt aber zu extrem wortreichen und sich wiederholenden Befehlaufrufen wie

   $ pip install --allow-external myproject --allow-unverified myproject myproject
   $ pip install --allow-all-external --allow-unverified myproject myproject
   

Repository-Seite

1. Außerbetriebnahme und Entfernung der durch PEP 438 definierten Hosting-Modi.
2. Beschränken Sie die Simple API so, dass nur die im Repository enthaltenen Dateien aufgelistet werden.

Client-Seite

1. Implementieren Sie die Unterstützung für mehrere Repositories.
2. Implementieren Sie einen Mechanismus zum Entfernen/Deaktivieren des Standard-Repositorys.
3. Außerbetriebnahme / Entfernung von PEP 438

Ich kann mein Projekt nicht auf PyPI hosten wegen <X>, was soll ich tun?

Zuerst sollten Sie entscheiden, ob <X> etwas ist, das PyPI inhärent ist, oder ob PyPI eine Funktion entwickeln könnte, um <X> für Sie zu lösen. Wenn PyPI eine Funktion hinzufügen kann, die es Ihnen ermöglicht, Ihr Projekt auf PyPI zu hosten, dann sollten Sie diese Funktion vorschlagen. Wenn <X> jedoch etwas ist, das PyPI inhärent ist, wie z. B. die Kontrolle über Ihre eigenen Dateien behalten zu wollen, dann sollten Sie Ihr eigenes Paket-Repository einrichten und Ihre Benutzer in der Projektbeschreibung anweisen, es zur Liste der Repositories hinzuzufügen, die ihr bevorzugter Installer verwenden soll.

Meine Benutzer haben eine schlechtere Erfahrung mit diesem PEP als zuvor, wie erkläre ich das?

Ein Teil dieser Antwort wird projektspezifisch sein. Sie müssen Ihren Benutzern erklären, warum Sie sich entschieden haben, in Ihrem eigenen Repository zu hosten, anstatt eines zu verwenden, das bereits in der Standardliste der Repositories ihres Installers enthalten ist. Ein Teil dieser Antwort wird jedoch auch erklären, dass das frühere Verhalten der transparenten Einbeziehung externer Links sowohl eine Sicherheitsgefahr darstellte (da es in den meisten Fällen einem MITM erlaubte, beliebigen Python-Code auf dem Rechner des Endbenutzers auszuführen) als auch ein Zuverlässigkeitsproblem darstellte und dass PEP 438 versuchte, dies zu lösen, indem er sie explizit zur Zustimmung zwang, aber dass PEP 438 eine Reihe schwerwiegender Usability-Probleme mit sich brachte. PEP 470 stellt eine Vereinfachung des Modells auf ein Modell dar, mit dem viele Benutzer vertraut sein werden, das bei Linux-Distributionen üblich ist.

Der Wechsel zu einer Repository-Struktur bricht meinen Workflow oder ist von meinem Hoster nicht erlaubt?

Es gibt eine Reihe von günstigen oder kostenlosen Hostern, die das, was für ein Repository erforderlich ist, gerne unterstützen würden. Insbesondere müssen Sie Ihre Dateien nicht tatsächlich anderswo hochladen, solange Sie einen Host mit der richtigen Struktur generieren können, der auf die tatsächlichen Speicherorte Ihrer Dateien verweist. Viele dieser Hoster bieten kostenloses HTTPS über einen gemeinsamen Domainnamen an, und kostenlose HTTPS-Zertifikate können von StartSSL oder in naher Zukunft von LetsEncrypt bezogen werden, oder sie können günstig von einer beliebigen Anzahl von Anbietern bezogen werden.

Warum bietet ihr <X> nicht an?

Die Antwort hierauf hängt davon ab, was <X> ist, aber die Antworten lauten typischerweise:

• Wir hatten nicht daran gedacht und niemand hatte es vorher vorgeschlagen.
• Wir haben nicht genügend Erfahrung mit <X>, um eine Lösung dafür richtig zu entwickeln, und würden uns über einen Domänenexperten freuen, der uns bei der Bereitstellung hilft.
• Wir sind ein Open-Source-Projekt und niemand hat sich entschieden, <X> zu entwerfen und zu implementieren.

Zusätzliche PEPs zur Vorstellung weiterer Funktionen sind immer willkommen, allerdings müssten sie jemanden mit der Zeit und Expertise enthalten, um <X> genau zu entwerfen. Dieses spezielle PEP zielt darauf ab, uns zu einem Punkt zu bringen, an dem die Fähigkeiten von PyPI klar und verständlich sind und einem leicht verständlichen Grundgerüst ähneln, das bestehenden Modellen wie Linux-Distributions-Repositories ähnelt.

Warum sollte ich mich auf PyPI registrieren, wenn ich sowieso mein eigenes Repository betreibe?

PyPI erfüllt zwei kritische Funktionen für das Python-Ökosystem. Eine davon ist die als zentrales Repository für die tatsächlichen Dateien, die von pip oder einem anderen Paketmanager heruntergeladen und installiert werden, und es ist diese Funktion, die dieses PEP betrifft und die Sie ersetzen würden, wenn Sie Ihr eigenes Repository betreiben. Sie bietet jedoch auch eine zentrale Registrierung, wer welche Namen besitzt, um Namenskollisionen zu verhindern. Betrachten Sie es quasi als DNS, aber für Python-Pakete. Neben der Sicherstellung, dass Namen nach dem Prinzip "Wer zuerst kommt, mahlt zuerst" vergeben werden, bietet sie auch einen einzigen Ort, an den sich Benutzer wenden können, um neue Projekte zu suchen und zu entdecken. Die einfache Antwort lautet also: Sie sollten Ihr Projekt immer noch bei PyPI registrieren, um Namenskollisionen zu vermeiden und sicherzustellen, dass die Leute Ihr Projekt immer noch leicht entdecken können.

Ermöglichen Sie eine einfachere Entdeckung von extern gehosteten Indizes

Eine frühere Version dieses PEP enthielt eine neue Funktion, die sowohl PyPI als auch Installern hinzugefügt wurde und es Projektentwicklern ermöglichen würde, eine Liste von URLs in PyPI einzugeben, die Installer anweisen würden, alle auf PyPI hochgeladenen Dateien zu ignorieren und stattdessen einen Fehler zurückzugeben, der den Endbenutzer über diese zusätzlichen URLs informiert, die er zu seinem Installer hinzufügen kann, um die Installation zu ermöglichen.

Diese Funktion wurde aus dem Umfang des PEP entfernt, da es sich als zu schwierig erwies, eine Lösung zu entwickeln, die UX-Probleme vermied, ähnlich denen, die mit der Lösung von PEP 438 so viele Probleme verursachten. Bei Bedarf könnte ein zukünftiges PEP diese Idee erneut aufgreifen.

Behalten Sie das aktuelle Klassifizierungssystem bei, passen Sie jedoch die Optionen an

Dieses PEP lehnt mehrere verwandte Vorschläge ab, die versuchen, einige der Usability-Probleme mit dem aktuellen System zu beheben, aber dennoch den allgemeinen Kern von PEP 438 beizubehalten.

Dazu gehören

• Standardmäßig sicher extern gehostete Dateien zulassen, aber unsicher gehostete verbieten.
• Standardmäßig sicher extern gehostete Dateien verbieten, mit nur einem globalen Flag, um sie zu aktivieren, aber unsicher gehostete verbieten.
• Dem empfohlenen Weg von PEP 438 folgen und die Option für unsicheres externes Hosting entfernen, aber weiterhin die Option für sicheres externes Hosting zulassen.

Diese Vorschläge werden abgelehnt, weil

• Das in PEP 438 eingeführte Klassifizierungssystem ist ein völlig einzigartiges Konzept für PyPI, das selbst im Kontext des Python-Paketmanagements nicht allgemein anwendbar ist. Das Hinzufügen weiterer Konzepte hat seinen Preis.
• Das Klassifizierungssystem selbst ist nicht offensichtlich zu erklären, und um vorherzubestimmen, welche Klassifizierung ein Projekt erfordert, muss die `/simple/<project>/`-Seite des Projekts und möglicherweise alle von dieser Seite verlinkten URLs inspiziert werden.
• Die Möglichkeit, extern zu hosten und trotzdem für die automatische Entdeckung verlinkt zu werden, ist hauptsächlich ein historisches Relikt, das viel Schmerz und Komplexität bei geringem Nutzen verursacht.
• Die Fähigkeit des Installers, die Benutzeroberfläche zu optimieren oder aufzuräumen, ist aufgrund der impliziten Link-Scraping, die durchgeführt werden müsste, begrenzt. Dies erstreckt sich auch auf die `--allow-*`-Optionen sowie auf die Unfähigkeit, festzustellen, ob ein Link voraussichtlich fehlschlägt oder nicht.
• Der Mechanismus verwendet eine sehr breite Bürste, wenn eine Option aktiviert wird, während PEP 438 versucht, dies mit Paketspezifischen Optionen einzuschränken. Ein seit langer Zeit bestehendes Projekt kann jedoch oft mehrere verschiedene URLs in seinem einfachen Index haben. Es ist nicht ungewöhnlich, dass mindestens eine davon nicht mehr unter der Kontrolle des Projekts steht. Während eine nicht registrierte Domäne meist harmlos bleibt, wird pip bei jeder Entdeckungsphase weiterhin versuchen, von ihr zu installieren. Das bedeutet, dass ein Angreifer lediglich nach Projekten suchen muss, die unsichere externe URLs verwenden, und abgelaufene Domains registrieren muss, um Benutzer anzugreifen.

Implementieren Sie dieses PEP, aber entfernen Sie nicht die bestehenden Links

Dies ist im Wesentlichen die abwärtskompatible Version dieses PEP. Es wird versucht, Personen, die ältere Clients oder Clients verwenden, die dieses PEP nicht implementieren, weiterhin so zu behandeln, als ob sich nichts geändert hätte. Dieser Vorschlag wird abgelehnt, da die überwiegende Mehrheit dieser Szenarien unsichere Verwendungen der außer Betrieb genommenen Funktionen sind. Es ist die Meinung dieses PEP, dass das stille Zulassen von unsicheren Aktionen im Namen von Endbenutzern einfach keine akzeptable Lösung ist.