PEP 755 – Implizite Namespace-Richtlinie für PyPI
- Autor:
- Ofek Lev <ofekmeister at gmail.com>
- Sponsor:
- Barry Warsaw <barry at python.org>
- PEP-Delegate:
- Dustin Ingram <di at python.org>
- Discussions-To:
- Discourse thread
- Status:
- Entwurf
- Typ:
- Prozess
- Thema:
- Packaging
- Erstellt:
- 05-Sep-2024
- Post-History:
- 07-Sep-2024
Zusammenfassung
Dieses PEP kodifiziert eine Implementierung von PEP 752 für PyPI [1].
Motivation
Viele Projekte und Communities würden von der Möglichkeit profitieren, Namespaces zu reservieren. Da PyPI dazu dient, die Python-Community zu unterstützen, ist es entscheidend, Feedback zu sammeln, um sicherzustellen, dass die Bedürfnisse aller erfüllt werden.
Ein dediziertes PEP ist erforderlich, da die operativen und politischen Nuancen von jedem Paket-Repository selbst entschieden werden müssen.
Begründung
PyPI war unterbesetzt und erhielt im Juli 2024 den ersten dedizierten Spezialisten. Aufgrund fehlender Ressourcen mangelte es beim Benutzersupport für Paketnamen-Ansprüche, Organisationsanfragen, Erhöhungen von Speicherlimits und sogar Konto-Wiederherstellungen.
Die Standardrichtlinie, bezahlten Organisationen mehr Nachsicht bei der Reservierung von Namespaces zu gewähren, bietet folgende Vorteile:
- PyPI hätte eine konstante Finanzierungsquelle für Support-Spezialisten, Infrastrukturwartung, Fehlerbehebungen und neue Funktionen.
- Obwohl jede Anwendung eine unabhängige Überprüfung erfordern würde, wäre weniger menschliches Feedback erforderlich, da der Prozess der Genehmigung einer bezahlten Organisation bereits ein gewisses Vertrauen verleiht.
Terminologie
- Bezahlte/Unternehmensorganisation
- Unternehmensorganisationen sind Organisationen, die für spezielle Funktionalitäten auf PyPI bezahlen. Dieses PEP bezieht sich der Kürze halber und zur einfacheren Verständlichkeit für Nicht-Muttersprachler in den meisten Fällen auf sie als "bezahlt".
- Root-Grant
- Ein Grant, wie definiert in der Terminologie von PEP 752.
- Child-Grant
- Ein Grant, der aus einem Root-Grant erstellt wurde und dessen zugehöriger Namespace ein untergeordneter Namespace ist, wie definiert in der Terminologie von PEP 752.
Implementierung
Grant-Anträge
Einreichung
Nur Organisations- (nicht Benutzer-) Konten haben Zugriff auf das Antragsformular für Grants.
Anträge von bezahlten Organisationen erhalten Priorität in der Überprüfungsschlange. Dies dient sowohl dazu, bezahlten Organisationen einen spürbaren Vorteil zu bieten als auch sicherzustellen, dass Finanzmittel für die operativen Kosten von PyPI, einschließlich zusätzlicher Prüfer, zur Verfügung stehen.
Zulassungskriterien
- Der Namespace darf nichts Gängiges sein wie
tooloderapps. - Der Namespace sollte mehr als drei Zeichen lang sein.
- Der Namespace sollte den Reservierungsbesitzer korrekt und klar identifizieren.
- Die Organisation sollte den Namespace aktiv nutzen.
- Es sollte Beweise dafür geben, dass die *Nicht*-Reservierung des Namespaces Mehrdeutigkeit, Verwirrung oder anderen Schaden für die Community verursachen könnte.
Organisationen, die keine bezahlten Organisationen sind, repräsentieren eine der folgenden:
- Große, beliebte Open-Source-Projekte mit vielen Paketen
- Universitäten, die aktiv Pakete veröffentlichen
- Regierungsorganisationen, die aktiv Pakete veröffentlichen
- NPO/NGOs, die aktiv Pakete veröffentlichen, wie z.B. Our World in Data
Generell sollten Prüfer toleranter gegenüber bezahlten Organisationen sein, die Grants beantragen, die sie noch nicht nutzen.
Zum Beispiel ist es zwar angemessen, einem Startup oder einem bestehenden Unternehmen mit einer neuen Produktlinie einen Namespace zu gewähren, aber es ist nicht so angemessen, einem Community-Projekt ohne viele Benutzer einen Namespace zu gewähren.
Ablehnungen
Abgelehnte Anträge erhalten eine klare Begründung für die Entscheidung basierend auf den Zulassungskriterien. Anträge, die aufgrund eines zu gängigen Namespace abgelehnt wurden, werden intern gespeichert, damit zukünftige Prüfer sie nachschlagen können, und neue Anträge, die versuchen, einen Namespace zu reservieren, der aus diesem Grund zuvor abgelehnt wurde, zeigen eine Warnung an.
Akzeptanz
Wenn ein Antrag für einen Namespace angenommen wird, der von Projekten außerhalb der Organisation verwendet wird, wird eine E-Mail an die Besitzer der Projekte gesendet, die sie über den neuen Grant informiert. Die E-Mail enthält einen Link zur Namespace-Seite.
Grant-Typen
Es gibt zwei Arten von Grants.
Root-Grant
Eine Organisation erhält für jede genehmigte Bewerbung einen Root-Grant. Dieser Grant kann eine beliebige Anzahl von Child-Grants erzeugen.
Child-Grant
Ein Child-Grant kann jederzeit vom Besitzer eines Root-Grants ohne Genehmigung erstellt werden. Der mit solchen Grants verbundene Namespace muss ein untergeordneter Namespace des Root-Grant-Namespaces sein.
Child-Grants können keine eigenen Child-Grants haben.
Grant-Besitz
Der Besitzer eines Grants kann einer beliebigen Anzahl anderer Organisationen die Nutzung des Grants erlauben. Die Grants verhalten sich so, als wären sie im Besitz der Organisation, d.h. selbst der Besitzer kann keine Pakete in den Namespace hochladen. Der Besitzer kann diese Erlaubnis jederzeit widerrufen.
Der Besitzer kann die Eigentümerschaft jederzeit auf eine andere Organisation übertragen, ohne die Genehmigung von PyPI-Administratoren. Wenn die Organisation eine bezahlte Organisation ist, muss das Ziel der Übertragung ebenfalls eine bezahlte Organisation sein. Einstellungen für erlaubte Organisationen werden ebenfalls übertragen.
Benutzeroberfläche
Namespace-Seite
Der Namespace jedes aktiven Grants erhält eine eigene Seite mit Informationen wie seinem offenen Status, den aktuellen Besitzern, dem Zeitpunkt der Gewährung des Eigentums und der Gesamtzahl der übereinstimmenden Projekte.
Projektseite
Jede Projektseite (Beispiel), die mit einem aktiven Namespace-Grant übereinstimmt, wird angeben, welches das Präfix ist (NuGet tut dies derzeit nicht) und wird als "Pill" oder Label hervorgehoben. Dieser Wert entspricht dem prefix-Schlüssel in der Namespace-Detail-API.
Ein Klick auf den Namespace führt den Benutzer zu seiner Seite.
Visuelle Indikatoren
Bei Projekten, die mit einem aktiven Namespace-Grant übereinstimmen, können Benutzer schnell feststellen, welches der folgenden Szenarien zutrifft:
- Projekte, die mit einem Grant-Besitzer verknüpft sind, haben keinen visuellen Indikator und Benutzer sollten sich ausschließlich auf das immer vorhandene Präfix verlassen.
- Projekte, die nicht mit einem Grant-Besitzer verknüpft sind und deren passender Grant offen ist, erhalten einen eindeutigen Indikator, der kein Misstrauen oder Gefahr ausdrückt. Eine gute Wahl könnte das Benutzer-Symbol von Font Awesome oder das Gruppen-Symbol von Google Fonts sein.
- Projekte, die nicht mit einem Grant-Besitzer verknüpft sind und deren passender Grant eingeschränkt ist, erhalten einen eindeutigen visuellen Indikator. Diese Situation tritt ein, wenn das Projekt vor der Erstellung des Grants existierte. Der Indikator wird Inauthentizität oder Mangel an Vertrauen vermitteln. Eine gute Wahl könnte ein Warnschild (⚠) sein.
Offene Namespaces
Wenn ein Child-Grant erstellt wird, wird sein offener Status vom Root-Grant geerbt. Besitzer von Child-Grants können diese jederzeit öffnen. Wenn ein Grant offen ist, kann er nicht eingeschränkt werden, es sei denn, der Besitzer des Grants ist der Besitzer jedes Projekts, das mit dem Namespace übereinstimmt.
Grant-Entfernung
Wenn ein Grant mit anderen Organisationen geteilt wird, muss die Besitzerorganisation eine Übertragung als Voraussetzung für die Löschung der Organisation einleiten.
Wenn ein Grant nicht geteilt wird, kann der Besitzer den Namespace unter einer der folgenden Umstände freigeben:
- Die Organisation entfernt sich manuell als Besitzer.
- Die Organisation wird gelöscht.
Wenn ein reservierter Namespace freigegeben wird, spiegelt die Benutzeroberfläche dies wider, sodass übereinstimmende Projekte keine Indikatoren mehr auf ihrer Seite haben und der Namespace keine eigene Seite mehr besitzt.
Wie man das lehrt
Für Organisationen werden wir dokumentieren, wie Namespaces reserviert werden, welche Vorteile sie bieten und welche Preise gelten.
Wir werden PEP 541 auf denselben Seiten dokumentieren, damit Organisationen den Hauptmechanismus kennen, um unsachgemäße Verwendungen bestehender Pakete, die mit ihren Grants übereinstimmen, zu melden.
Abgelehnte Ideen
Seite zur Ansicht aller aktiven Grants
Es gibt keine Seite zur Ansicht aller aktiven Namespace-Grants, da dies das Potenzial hat, private Informationen wie zukünftige Produkte preiszugeben.
Visueller Indikator für eigene Projekte
Es gibt keinen Indikator für Projekte, die mit einem Grant-Besitzer verknüpft sind, hauptsächlich um Unordnung zu reduzieren, da dies das häufigste Szenario ist.
Wenn es einen Indikator gäbe, wäre es kein Häkchen oder Ähnliches, wie NuGet es wählte, da es fälschlicherweise vermitteln könnte, dass mit der Nutzung des Pakets verbundene Sicherheitsgarantien bestehen. Außerdem verwenden einige soziale Medienplattformen ein Häkchen für verifizierte Benutzer, was zu Verwirrung führen kann.
Referenzen
Urheberrecht
Dieses Dokument wird in die Public Domain oder unter die CC0-1.0-Universal-Lizenz gestellt, je nachdem, welche Lizenz permissiver ist.
Quelle: https://github.com/python/peps/blob/main/peps/pep-0755.rst
Zuletzt geändert: 2025-03-20 22:51:26 GMT