Anwendungsfälle

Das geänderte Verhalten in diesem PEP soll „das Richtige tun“ für so viele Anwendungsfälle wie möglich. In diesem Abschnitt betrachten wir die durch dieses PEP spezifizierten Änderungen für mehrere repräsentative Anwendungsfälle / Kontexte. Insbesondere fragen wir nach den beiden Verhaltensweisen, die durch dieses PEP geändert werden könnten

1. Wird ein Python-spezifisches Installationswerkzeug wie pip install standardmäßig Installationen zulassen, nachdem dieses PEP implementiert wurde?
2. Wenn Sie ein solches Werkzeug ausführen, sollte es dann erwünscht sein, von externen (nicht Python-spezifischen) Paketmanagern für diesen Kontext ausgelieferte Pakete zu löschen, wie z. B. einen Distro-Paketmanager?

(Der Einfachheit halber diskutiert dieser Abschnitt pip als das Python-spezifische Installationswerkzeug, obwohl die Analyse gleichermaßen auf jedes andere Python-spezifische Paketmanagement-Tool anwendbar sein sollte.)

Diese Tabelle fasst die unten detailliert diskutierten Anwendungsfälle zusammen

Im Detail sind die obigen Anwendungsfälle

1. Ein Standard-ungepatchtes CPython, ohne spezielle Konfiguration oder Patches für sysconfig und ohne Markerdatei. Dieses PEP ändert sein Verhalten nicht.

   Ein solches CPython sollte (unabhängig von diesem PEP) nicht so installiert werden, dass es sich mit einem von der Distro installierten Python im selben System überschneidet. Zum Beispiel sollten Sie auf einem OS, das Python in /usr/bin ausliefert, kein benutzerdefiniertes CPython installieren, das mit ./configure --prefix=/usr gebaut wurde, da dies einige Dateien der Distro überschreiben würde und die Distro schließlich einige Dateien Ihrer Installation überschreiben würde. Stattdessen sollte Ihre Installation in einem separaten Verzeichnis erfolgen (vielleicht /usr/local, /opt oder Ihrem Home-Verzeichnis).

   Daher können wir davon ausgehen, dass ein solches CPython über ein eigenes stdlib-Verzeichnis und eigene sysconfig-Schemas verfügt, die sich nicht mit einem von der Distro installierten Python überschneiden. Daher sind alle von der OS installierten Pakete hier nicht sichtbar oder relevant.

   Wenn in diesem Fall ein Konzept von „extern installierten“ Paketen existiert, dann ist es etwas außerhalb des OS und wird im Allgemeinen von demjenigen verwaltet, der dieses CPython gebaut und installiert hat. Da der Installer sich dafür entschieden hat, keine Markerdatei hinzuzufügen oder die sysconfig-Schemas zu ändern, wählt er das aktuelle Verhalten, und pip install kann alle in diesem CPython verfügbaren Pakete entfernen.

2. Ein /usr/bin/python3 einer Distro, entweder wenn pip install als Root ausgeführt wird oder pip install --user, gemäß unseren Empfehlungen für Distros.

   Diese Empfehlungen beinhalten das Ausliefern einer Markerdatei im stdlib-Verzeichnis, um pip install standardmäßig zu verhindern, und das Platzieren von von der Distro ausgelieferten Paketen an einem Ort, der vom Standard- sysconfig-Schema abweicht, sodass pip als Root nicht in diesen Speicherort schreibt.

   Viele Distros (einschließlich Debian, Fedora und ihrer Derivate) tun bereits Letzteres.

   Unter Debian und Derivaten löscht pip install derzeit keine von der Distro installierten Pakete, da Debian einen Patch für pip hat, um dies zu verhindern. Für diese Distros ist dieses PEP also keine Verhaltensänderung; es standardisiert dieses Verhalten lediglich auf eine Weise, die nicht mehr Debian-spezifisch ist und in das Upstream-pip integriert werden kann.

   (Wir haben Benutzerberichte gesehen, dass extern installierte Pakete unter Debian oder einem Derivat gelöscht wurden. Wir vermuten, dass dies daran liegt, dass der Benutzer zuvor sudo pip install --upgrade pip ausgeführt hat und daher nun eine Version von /usr/bin/pip ohne den Debian-Patch hat; die Standardisierung dieses Verhaltens in Upstream-Paketinstallern würde dieses Problem lösen.)

3. Ein Distro-Python, wenn es innerhalb einer virtuellen Umgebung verwendet wird (entweder von venv oder virtualenv).

   Innerhalb einer virtuellen Umgebung gehören alle Pakete dieser Umgebung. Selbst wenn pip, setuptools usw. in die Umgebung installiert werden, werden sie von Tools verwaltet, die für diese Umgebung spezifisch sind, und sollten es auch sein; sie sind nicht systemverwaltet.

4. Ein Distro-Python, wenn es innerhalb einer virtuellen Umgebung mit --system-site-packages verwendet wird. Dies ist wie der vorherige Fall, aber es lohnt sich, es ausdrücklich zu erwähnen, da alles auf dem globalen sys.path sichtbar ist.

   Derzeit lautet die Antwort auf die Frage „Löscht pip extern installierte Pakete“ nein, da pip einen Sonderfall für die Ausführung in einer virtuellen Umgebung und den Versuch, Pakete außerhalb davon zu löschen, hat. Nach diesem PEP bleibt die Antwort nein, aber die Begründung wird allgemeiner: System-Site-Pakete werden außerhalb aller sysconfig-Schemas liegen, die für die Paketverwaltung in der Umgebung verwendet werden.

5. Ein Distro-Python, wenn es in einem Single-Application-Container-Image (z. B. einem Docker-Container) verwendet wird. In diesem Anwendungsfall ist das Risiko, Systemsoftware zu beschädigen, geringer, da im Allgemeinen nur eine einzige Anwendung im Container läuft, und die Auswirkungen sind geringer, da Sie den Container neu erstellen können und nicht mit der Wiederherstellung einer laufenden Maschine kämpfen müssen. Es gibt auch eine große Anzahl bestehender Dockerfiles mit einer nicht qualifizierten RUN pip install ...-Anweisung usw., und es wäre gut, diese nicht zu brechen. Daher möchten die Ersteller von Basis-Container-Images möglicherweise sicherstellen, dass die Markerdatei nicht vorhanden ist, selbst wenn das zugrunde liegende Betriebssystem eine standardmäßig ausliefert.

   Es gibt eine kleine Verhaltensänderung: Derzeit löscht pip als Root extern installierte Pakete, aber nach diesem PEP wird es dies nicht mehr tun. Wir schlagen keine Möglichkeit vor, dies zu überschreiben. Da das Basis-Image jedoch im Allgemeinen minimal ist, sollte es keinen großen Anwendungsfall für die einfache Deinstallation von Paketen geben (insbesondere ohne die eigenen Werkzeuge der Distro zu verwenden). Der häufigste Fall ist, wenn pip ein Paket aktualisieren möchte, was zuvor die alte Version gelöscht hätte (außer unter Debian). Nach dieser Änderung ist die alte Version noch auf der Festplatte, aber pip wird extern installierte Pakete weiterhin **schatten**, und wir glauben, dass dies ausreicht, damit dies in der Praxis keine Breaking Change darstellt – eine Python- import-Anweisung führt Sie immer noch zum neu installierten Paket.

   Wenn es notwendig wird, eine solche Möglichkeit zu haben, schlagen wir vor, dass die Distro einen Weg dokumentiert, wie das Installationswerkzeug auf das von der Distro selbst verwendete sysconfig-Schema zugreifen kann. Siehe den Abschnitt Empfehlungen für Distros für weitere Diskussionen.

   Nach Ansicht der Autoren dieses PEP ist es immer noch eine gute Idee, virtuelle Umgebungen mit von der Distro installierten Python-Interpretern zu verwenden, selbst in Single-Application-Container-Images. Auch wenn sie eine einzige *Anwendung* ausführen, kann diese Anwendung Befehle des Betriebssystems ausführen, die in Python implementiert sind, und wenn Sie die von der Distro ausgelieferten Python-Pakete mit Python-spezifischen Tools installiert oder aktualisiert haben, können diese Befehle brechen.

6. Conda unterstützt ausdrücklich die Verwendung von Nicht- conda-Tools wie pip zur Installation von Software, die nicht in den Conda-Repositorys verfügbar ist. In diesem Kontext fungiert Conda als externer Paketmanager/Distro und pip als der Python-spezifische.

   In gewisser Weise ist dies dem ersten Fall ähnlich, da Conda eine eigene Installation des Python-Interpreters bereitstellt.

   Wir glauben nicht, dass dieses PEP Änderungen an Conda erfordert, und Versionen von pip, die die Änderungen in diesem PEP implementiert haben, werden sich weiterhin wie bisher innerhalb von Conda-Umgebungen verhalten. (Dennoch könnte es sich lohnen zu überlegen, ob separate sysconfig-Schemas für pip-installierte und Conda-installierte Software verwendet werden sollen, aus denselben Gründen, aus denen es für andere Distros eine gute Idee ist.)

7. Mit einer „entwicklerorientierten Distro“ meinen wir eine spezifische Art von Distro, bei der von direkten Benutzern von Python oder anderen Sprachen in der Distro erwartet oder ermutigt wird, Änderungen an der Distro selbst vorzunehmen, wenn sie Bibliotheken hinzufügen möchten. Häufige Beispiele sind private „Monorepos“ in Softwareentwicklungsunternehmen, in denen ein einziges Repository sowohl Drittanbieter- als auch Inhouse-Software erstellt und die direkten Benutzer des Python-Interpreters der Distro im Allgemeinen Softwareentwickler sind, die besagte Inhouse-Software schreiben. Benutzerdefinierte Paketmanager wie Nixpkgs können ebenfalls dazugehören, da sie Benutzer von Nix, die Python-Entwickler sind, dazu ermutigen, ihre Software für Nix zu verpacken.

   In diesen Fällen möchte die Distro möglicherweise auf einen Versuch von pip install mit Anleitungen reagieren, die die Verwendung der eigenen Einrichtungen der Distro zum Hinzufügen neuer Pakete fördern, zusammen mit einem Link zur Dokumentation.

   Wenn die Distro das Erstellen einer virtuellen Umgebung aus dem Python-Interpreter der Distro unterstützt/ermutigt, kann es auch benutzerdefinierte Anweisungen geben, wie eine virtuelle Umgebung richtig eingerichtet wird (wie z. B. Nixpkgs es tut).

8. Beim Erstellen von Distro-Python-Paketen für eine Distro-Python (Fall 2) kann es nützlich sein, pip install als Teil des Paketbauprozesses der Distro verwenden zu können. (Denken Sie zum Beispiel daran, ein python-xyz RPM zu bauen, indem Sie pip install . innerhalb eines sdist / Source-Tarballs für xyz verwenden.) Die Distro möchte möglicherweise auch ein gezielteres, aber immer noch Python-spezifisches Installationswerkzeug wie installer verwenden.

   Für diesen Fall muss der Bauprozess einen Weg finden, die Markerdatei zu unterdrücken, um pip install zu ermöglichen, und wird wahrscheinlich das Python-spezifische Werkzeug auf das sysconfig-Schema der Distro anstelle des ausgelieferten Standards verweisen müssen. Siehe den Abschnitt Empfehlungen für Distros für weitere Diskussionen zur Implementierung.

   Als Ergebnis dieses PEP kann pip bereits installierte Pakete nicht mehr entfernen. Diese Verhaltensänderung ist jedoch in Ordnung, da ein Paketbauprozess keine Anweisungen zum Löschen anderer Systemdateien enthalten sollte (und im Allgemeinen auch nicht kann); er kann nur seine eigenen Dateien verpacken.

9. Ein Distro-Python, das mit PYTHONHOME verwendet wird, um eine alternative Python-Umgebung einzurichten (im Gegensatz zu einer virtuellen Umgebung), wobei PYTHONHOME auf ein Verzeichnis gesetzt wird, das direkt aus dem Distro-Python kopiert wurde (z. B. cp -a /usr/lib/python3.x pyhome/lib).

   Unter der Annahme, dass es keine Modifikationen gibt, verhält es sich genau wie das zugrunde liegende Distro-Python (Fall 2). Es gibt also Verhaltensänderungen – Sie können standardmäßig nicht mehr pip install, und wenn Sie es überschreiben, werden keine extern installierten Pakete mehr gelöscht (d. h. Python-Pakete, die vom OS kopiert wurden und sich im OS-verwalteten sys.path-Eintrag befinden).

   Diese Verhaltensänderung scheint vertretbar zu sein, da, wenn Ihr PYTHONHOME eine exakte Kopie des Distro-Pythons ist, es sich wie das Distro-Python verhalten sollte.

10. Ein Distro-Python (oder ein beliebiger Python-Interpreter), der mit einem PYTHONHOME verwendet wird, das von einem kompatiblen, unveränderten Upstream-Python stammt.

    Da die Verhaltensänderungen in diesem PEP an Dateien in der Standardbibliothek geknüpft sind (die Markerdatei in stdlib und das Verhalten des sysconfig-Moduls), ist das Verhalten genau wie bei einem unveränderten Upstream-CPython (Fall 1).

Markieren eines Interpreters als extern verwaltet

Bevor ein Python-spezifischer Paketinstaller (das heißt, ein Tool wie pip – kein externes Tool wie apt) ein Paket in einen bestimmten Python-Kontext installiert, sollte er standardmäßig die folgenden Prüfungen durchführen

1. Läuft er außerhalb einer virtuellen Umgebung? Dies kann er feststellen, indem er prüft, ob sys.prefix == sys.base_prefix ist (aber siehe Rückwärtskompatibilität).
2. Gibt es eine Datei EXTERNALLY-MANAGED in dem Verzeichnis, das von sysconfig.get_path("stdlib", sysconfig.get_default_scheme()) identifiziert wird?

Wenn beide Bedingungen erfüllt sind, sollte der Installer mit einer Fehlermeldung beendet werden, die darauf hinweist, dass die Paketinstallation in das Verzeichnis dieses Python-Interpreters außerhalb einer virtuellen Umgebung deaktiviert ist.

Der Installer sollte eine Möglichkeit für den Benutzer haben, diese Regeln zu überschreiben, z. B. durch ein Befehlszeilenflag --break-system-packages. Diese Option sollte nicht standardmäßig aktiviert sein und sollte eine gewisse Konnotation tragen, dass ihre Verwendung riskant ist.

Die Datei EXTERNALLY-MANAGED ist eine Metadatendatei im INI-Stil, die vom Standardbibliotheksmodul configparser geparst werden kann. Wenn die Datei mit configparser.ConfigParser(interpolation=None) unter Verwendung der UTF-8-Kodierung geparst werden kann und eine Sektion [externally-managed] enthält, sollte der Installer eine in der Datei angegebene Fehlermeldung suchen und diese als Teil seines Fehlers ausgeben. Wenn das erste Element des von locale.getlocale(locale.LC_MESSAGES) zurückgegebenen Tupels, d. h. der Sprachcode, nicht None ist, sollte er nach der Fehlermeldung als Wert eines Schlüssels namens Error- gefolgt vom Sprachcode suchen. Wenn dieser Schlüssel nicht existiert und der Sprachcode Unterstriche oder Bindestriche enthält, sollte er nach einem Schlüssel namens Error- gefolgt vom Teil des Sprachcodes vor dem Unterstrich oder Bindestrich suchen. Wenn keiner von beiden gefunden wird oder der Sprachcode None ist, sollte er nach einem Schlüssel namens Error suchen.

Wenn der Installer keine Fehlermeldung in der Datei findet (entweder weil die Datei nicht geparst werden kann oder weil kein geeigneter Fehlerschlüssel existiert), sollte der Installer eine vordefinierte Fehlermeldung verwenden, die den Benutzer auffordert, eine virtuelle Umgebung zum Installieren von Paketen zu erstellen.

Software-Distributoren, die einen nicht-Python-spezifischen Paketmanager haben, der Bibliotheken im sys.path ihres Python-Pakets verwaltet, sollten im Allgemeinen eine EXTERNALLY-MANAGED-Datei in ihrem Standardbibliotheksverzeichnis bereitstellen. Zum Beispiel kann Debian eine Datei in /usr/lib/python3.9/EXTERNALLY-MANAGED bereitstellen, die etwas wie Folgendes enthält:

[externally-managed]
Error=To install Python packages system-wide, try apt install
 python3-xyz, where xyz is the package you are trying to
 install.

 If you wish to install a non-Debian-packaged Python package,
 create a virtual environment using python3 -m venv path/to/venv.
 Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
 sure you have python3-full installed.

 If you wish to install a non-Debian packaged Python application,
 it may be easiest to use pipx install xyz, which will manage a
 virtual environment for you. Make sure you have pipx installed.

 See /usr/share/doc/python3.9/README.venv for more information.

was nützliche und distrubutionsspezifische Informationen für einen Benutzer liefert, der versucht, ein Paket zu installieren. Optional können Übersetzungen in derselben Datei bereitgestellt werden.

Error-de_DE=Wenn ist das Nunstück git und Slotermeyer?

 Ja! Beiherhund das Oder die Virtualenvironment gersput!

In bestimmten Kontexten, wie z. B. bei Container-Images für einzelne Anwendungen, die nach der Erstellung nicht aktualisiert werden, kann ein Distributor entscheiden, keine EXTERNALLY-MANAGED-Datei bereitzustellen, damit Benutzer alles installieren können, was sie möchten (wie heute möglich), ohne diese Regel manuell außer Kraft setzen zu müssen.

Schreiben nur in das Ziel sysconfig Schema

Normalerweise installiert ein Python-Paket-Installer in Verzeichnisse eines Schemas, das vom Standardbibliotheks-Paket sysconfig zurückgegeben wird. Normalerweise ist dies das von sysconfig.get_default_scheme() zurückgegebene Schema, aber basierend auf der Konfiguration (z. B. pip install --user) kann ein anderes Schema verwendet werden.

Immer wenn der Installer in ein sysconfig-Schema installiert, legt diese PEP fest, dass der Installer niemals Dateien außerhalb dieses Schemas ändern oder löschen darf. Wenn er beispielsweise ein Paket aktualisiert und das Paket bereits in einem Verzeichnis außerhalb dieses Schemas installiert ist (möglicherweise in einem Verzeichnis eines anderen Schemas), sollte er die vorhandenen Dateien unangetastet lassen.

Wenn der Installer während einer Aktualisierung eine bestehende Installation überschattet, empfehlen wir, dass er am Ende seines Laufs eine Warnung ausgibt.

Wenn der Installer an einen Ort außerhalb eines sysconfig-Schemas installiert (z. B. pip install --target), dann gilt dieser Unterabschnitt nicht.

Die Installation als extern verwaltet markieren

Distributoren sollten eine EXTERNALLY-MANAGED-Datei in ihrem stdlib-Verzeichnis erstellen.

Benutzer zu virtuellen Umgebungen leiten

Die Datei sollte eine nützliche und distributionsspezifische Fehlermeldung enthalten, die sowohl anzeigt, wie systemweite Pakete über den Paketmanager der Distribution installiert werden, als auch wie eine virtuelle Umgebung eingerichtet wird. Wenn Ihre Distribution häufig von Benutzern in einem Zustand verwendet wird, in dem der Befehl python3 verfügbar ist (und insbesondere, wenn pip oder get-pip verfügbar ist), python3 -m venv jedoch nicht funktioniert, sollte die Meldung klar angeben, wie python3 -m venv ordnungsgemäß funktioniert.

Erwägen Sie, pipx zu verpacken, ein Werkzeug zur Installation von Anwendungen in Python-Sprache, und es in der Fehlermeldung zu empfehlen. pipx erstellt automatisch eine virtuelle Umgebung nur für diese Anwendung, was eine viel bessere Standardeinstellung für Endbenutzer ist, die Python-Sprachsoftware (die in der Distribution nicht verfügbar ist) installieren möchten, aber selbst keine Python-Benutzer sind. Das Verpacken von pipx in der Distribution vermeidet die Ironie, Benutzer aufzufordern, pip install --user --break-system-packages pipx zu verwenden, um Systempakete *zu vermeiden* zu beschädigen. Erwägen Sie, Ihre Distribution so zu arrangieren, dass ihr Paket/Umgebung für Python für Endbenutzer (z. B. python3 unter Fedora oder python3-full unter Debian) von pipx abhängt.

Die Markerdatei in Container-Images beibehalten

Distributoren, die offizielle Images für Single-Application-Container (z. B. Docker-Container-Images) erstellen, sollten die EXTERNALLY-MANAGED-Datei beibehalten, vorzugsweise so, dass sie nicht verschwindet, wenn ein Benutzer dieses Images Paketaktualisierungen innerhalb seines Images installiert (denken Sie an RUN apt-get dist-upgrade).

Separate Distro- und lokale Verzeichnisse erstellen

Distributoren sollten zwei separate Pfade zum sys.path des Systeminterpreters legen, einen für von der Distribution installierte Pakete und einen für von lokalen Systemadministratoren installierte Pakete, und sysconfig.get_default_scheme() so konfigurieren, dass es auf den letzteren Pfad zeigt. Dies stellt sicher, dass Tools wie pip keine von der Distribution installierten Pakete ändern. Der Pfad für den lokalen Systemadministrator sollte vor dem Pfad der Distribution in sys.path stehen, damit lokale Installationen Vorrang vor Distributionspaketen haben.

Zum Beispiel implementieren Fedora und Debian (und ihre Derivate) diese Trennung, indem sie /usr/local für lokal installierte Pakete und /usr für von der Distribution installierte Pakete verwenden. Fedora verwendet /usr/local/lib/python3.x/site-packages im Vergleich zu /usr/lib/python3.x/site-packages. (Debian verwendet /usr/local/lib/python3/dist-packages im Vergleich zu /usr/lib/python3/dist-packages als zusätzliche Trennung von einem lokal kompilierten Python-Interpreter: Wenn Sie Upstream CPython in /usr/local/bin erstellen und installieren, wird /usr/local/lib/python3/site-packages betrachtet, und Debian möchte sicherstellen, dass über den lokal erstellten Interpreter installierte Pakete nicht im sys.path für den Distributionsinterpreter erscheinen.)

Beachten Sie, dass die Trennung /usr/local vs. /usr analog dazu ist, wie die Umgebungsvariable PATH typischerweise /usr/local/bin:/usr/bin enthält und Nicht-Distributionssoftware standardmäßig unter /usr/local installiert wird. Diese Trennung wird vom Filesystem Hierarchy Standard empfohlen.

Es gibt zwei Möglichkeiten, dies zu tun. Eine Möglichkeit ist, wenn Sie Python-Bibliotheken direkt bauen und verpacken (z. B. Ihre Verpackungshelfer entpacken ein mit PEP 517 erstelltes Wheel oder rufen setup.py install auf), dafür zu sorgen, dass diese Tools ein Verzeichnis verwenden, das nicht in einem sysconfig-Schema liegt, aber dennoch auf sys.path steht.

Die andere Möglichkeit ist, sicherzustellen, dass das Standard-sysconfig-Schema beim Ausführen innerhalb eines Paketbaus anders ist als bei einem installierten System. Die sysconfig-Anpassungshaken aus bpo-43976 sollten dies einfach machen (sobald sie akzeptiert und implementiert sind): Ihr Verpackungstool setzt eine Umgebungsvariable oder eine andere erkennbare Konfiguration und definiert eine Funktion get_preferred_schemes, die ein anderes Schema zurückgibt, wenn sie aus einem Paketbau aufgerufen wird. Dann können Sie pip install als Teil Ihrer Distributionsverpackung verwenden.

Wir schlagen vor, eine Option --scheme=... hinzuzufügen, um pip anzuweisen, gegen ein bestimmtes Schema zu laufen. (Siehe Implementierungsnotizen unten, wie pip Schemata aktuell ermittelt.) Sobald dies verfügbar ist, können Sie für lokale Tests und möglicherweise für die eigentliche Verpackung etwas wie pip install --scheme=posix_distro ausführen, um ein Paket explizit in den Speicherort Ihrer Distribution zu installieren (wobei get_preferred_schemes umgangen wird). Man könnte auch, wenn absolut notwendig, pip uninstall --scheme=posix_distro verwenden, um Pakete aus dem systemverwalteten Verzeichnis mit pip zu entfernen, was die (hoffentlich theoretische) Regression im Anwendungsfall 5 in Begründung behandelt.

Um Pakete mit pip zu installieren, müssten Sie entweder die EXTERNALLY-MANAGED-Markierungsdatei unterdrücken, damit pip ausgeführt werden kann, oder sie auf der Befehlszeile außer Kraft setzen. Möglicherweise möchten Sie dieselben Mittel zur Unterdrückung der Markierungsdatei in Build-Chroots wie in Container-Images verwenden.

Der Vorteil der automatischen Einrichtung dieser Dinge (Unterdrückung der Markierungsdatei in Ihrer Build-Umgebung und automatische Rückgabe Ihres Distributionsschemas durch get_preferred_schemes) ist, dass ein unmodifiziertes pip install innerhalb eines Paketbaus funktioniert, was im Allgemeinen bedeutet, dass ein unverändertes Upstream-Build-Skript, das intern pip install aufruft, das Richtige tut. Sie können natürlich auch sicherstellen, dass Ihr Verpackungsprozess immer pip install --scheme=posix_distro --break-system-packages aufruft, was ebenfalls funktionieren würde.

Der beste Ansatz hier hängt stark von den Konventionen und Mechanismen Ihrer Distribution für die Verpackung ab.

Ähnlich sollten die sysconfig-Pfade, die nicht für importierbaren Python-Code bestimmt sind – d. h. include, platinclude, scripts und data – ebenfalls zwei Varianten haben, eine für von der Distribution verpackte Software und eine für lokal installierte Software, und die Distribution sollte so eingerichtet sein, dass beide nutzbar sind. Zum Beispiel verwendet eine typische FHS-konforme Distribution /usr/local/include für das include des Standard-Schemas und /usr/include für von der Distribution verpackte Header und legt beide auf den Suchpfad des Compilers; und sie verwendet /usr/local/bin für die scripts des Standard-Schemas und /usr/bin für von der Distribution verpackte Einstiegspunkte und legt beide auf $PATH.

Markerdatei

Sollte die Markierungsdatei in sys.path liegen und ein bestimmtes Verzeichnis als nicht zu beschreibend durch einen Python-spezifischen Paketmanager markieren? Dies würde beim zweiten von dieser PEP behandelten Problem (nicht Überschreiben oder Löschen von Distributions-eigenen Dateien) helfen, aber nicht beim ersten (inkompatible Installationen). Eine Verzeichnis-spezifische Markierung in /usr/lib/python3.x/site-packages würde Installationen in /usr/local/lib/python3.x/site-packages oder ~/.local/lib/python3.x/site-packages nicht entmutigen, die beide auf sys.path für /usr/bin/python3 stehen. Mit anderen Worten, die Markierungsdatei sollte nicht als Kennzeichnung eines einzelnen *Verzeichnisses* als extern verwaltet interpretiert werden (obwohl sie sich zufällig in einem Verzeichnis auf sys.path befindet); sie kennzeichnet die gesamte *Python-Installation* als extern verwaltet.

Eine weitere Variante des Obigen: Sollte die Markierungsdatei in sys.path liegen, so dass, wenn sie in einem Verzeichnis in sys.path gefunden wird, sie die Installation als extern verwaltet markiert? Ein scheinbarer Vorteil dieses Ansatzes ist, dass er sich in virtuellen Umgebungen automatisch deaktiviert. Leider hat dies das falsche Verhalten bei einer virtuellen Umgebung mit --system-site-packages, bei der der systemweite sys.path sichtbar ist, aber Paketinstallationen erlaubt sind. (Es könnte funktionieren, wenn die Regel zur Befreiung von virtuellen Umgebungen beibehalten wird, aber das scheint keinen Vorteil gegenüber dem aktuellen Schema zu haben.)

Sollte die Markierung nur ein neues Attribut eines sysconfig-Schemas sein? Dies hat eine gewisse konzeptionelle Sauberkeit, außer dass es schwer zu überschreiben ist. Wir möchten es für Container-Images, Paketbauumgebungen usw. einfach machen, die Markierungsdatei zu unterdrücken. Eine Datei, die Sie entfernen können, ist einfach; Code in sysconfig ist viel schwieriger zu ändern.

Sollte die Datei in /etc liegen? Nein, denn auch hier bezieht sie sich auf eine bestimmte Python-Installation. Ein Benutzer, der sein eigenes Python installiert, möchte möglicherweise Pakete im globalen Kontext dieses Interpreters installieren.

Sollte die Konfigurationseinstellung in pip.conf oder distutils.cfg erfolgen? Abgesehen von den oben genannten Einwänden gegen die Kennzeichnung einer Installation ist dieser Mechanismus nicht spezifisch für eines dieser Tools. (Es erscheint vernünftig, dass pip *auch* ein Konfigurationsflag für Benutzer implementiert, um sie daran zu hindern, versehentlich Nicht-Virtual-Environment-Installationen in jeder Python-Installation durchzuführen, aber das liegt außerhalb des Rahmens dieser PEP.)

Sollte die Datei TOML sein? TOML gewinnt für die Verpackung an Popularität (siehe z. B. PEP 517), hat aber noch keine Implementierung in der Standardbibliothek. Streng genommen ist dies kein Hindernis – Distributoren müssen die Datei nur schreiben, nicht lesen, also brauchen sie keine TOML-Bibliothek (die Datei wird wahrscheinlich unabhängig vom Format von Hand geschrieben), und Verpackungstools haben wahrscheinlich bereits einen TOML-Reader. Das INI-Format wird jedoch derzeit für verschiedene andere Formen von Verpackungsmetadaten verwendet (z. B. pydistutils.cfg und setup.cfg), erfüllt unsere Anforderungen, kann von der Standardbibliothek geparst werden, und die pip-Wartungspersonen sprachen sich dafür aus, TOML hierfür noch nicht zu verwenden.

Sollte die Datei im email.message-Stil sein? Obwohl dieses Format auch für Verpackungsmetadaten verwendet wird (z. B. sdist- und Wheel-Metadaten) und auch von der Standardbibliothek geparst werden kann, werden mehrzeilige Einträge nicht ganz so klar gehandhabt, und das ist unser primärer Anwendungsfall.

Sollte die Markierungsdatei ausführbarer Python-Code sein, der bewertet, ob die Installation erlaubt sein soll oder nicht? Abgesehen von den oben genannten Bedenken, die Datei in sys.path zu haben, haben wir Bedenken, dass die Ausführbarkeit zu mächtig eine API festlegt und das Verhalten schwerer verständlich machen könnte. (Beachten Sie, dass der Hook get_default_scheme von bpo-43976 tatsächlich ausführbar ist, aber dieser Code muss beim Bau des Interpreters bereitgestellt werden; er ist nicht für die Bereitstellung nach dem Bau vorgesehen.)

Wenn die Markierung überschrieben wird, sollte ein Python-spezifischer Paketmanager daran gehindert werden, ein vom externen Paketmanager installiertes Paket zu überschatten (d. h. Module mit demselben Namen zu installieren)? Dies würde das Risiko, Systemsoftware zu beschädigen, minimieren, aber es ist nicht klar, ob es die zusätzliche Komplexität der Benutzererfahrung wert ist. Es gibt legitime Anwendungsfälle für das Überschatten von Systempaketen, und eine zusätzliche Befehlszeilenoption, um dies zu erlauben, wäre verwirrender. Unterdessen würde das Nicht-Übergeben dieser Option das Risiko, Systemsoftware zu beschädigen, nicht beseitigen, die sich möglicherweise auf ein try: import xyz verlassen, das fehlschlägt, eine begrenzte Menge an Einstiegspunkten findet usw. Die Kommunikation dieser Unterscheidung scheint schwierig. Wir denken, es ist gut, wenn Python-spezifische Paketmanager eine Warnung ausgeben, wenn sie ein Paket überschatten, aber wir denken nicht, dass es sich lohnt, dies standardmäßig zu deaktivieren.

Warum wird die INSTALLER-Datei aus PEP 376 nicht verwendet, um festzustellen, wer ein Paket installiert hat und ob es entfernt werden kann? Erstens ist sie spezifisch für ein bestimmtes Paket (sie befindet sich im dist-info-Verzeichnis des Pakets), so dass sie, wie einige der oben genannten Alternativen, keine Informationen über eine gesamte Umgebung und die Zulässigkeit von Paketinstallationen liefert. PEP 627 aktualisiert auch PEP 376, um die programmatische Verwendung von INSTALLER zu verhindern, und legt fest, dass die Datei „nur zu Informationszwecken verwendet wird. [...] Unser Ziel ist die Unterstützung von Interoperabilitätstools, und jede Aktion basierend darauf, welches Tool ein Paket installiert hat, widerspricht diesem Ziel.“ Schließlich, wie PEP 627 vorsieht, gibt es legitime Anwendungsfälle dafür, dass ein Tool weiß, wie es von einem anderen Tool installierte Pakete behandeln kann; zum Beispiel kann conda ein von pip in einer Conda-Umgebung installiertes Paket sicher entfernen.

Warum gibt die Spezifikation keine Möglichkeit, Paketinstallationen innerhalb einer virtuellen Umgebung zu deaktivieren? Wir können keinen besonders starken Anwendungsfall dafür erkennen (zumindest keinen, der mit den Zielen dieser PEP zusammenhängt). Wenn Sie ihn brauchen, ist es einfach genug, pip uninstall pip innerhalb dieser Umgebung auszuführen, was zumindest unbeabsichtigte Änderungen an der Umgebung verhindern sollte (und diese Spezifikation sieht keine Vorkehrungen vor, um *absichtliche* Änderungen zu deaktivieren, da die Markierungsdatei schließlich leicht entfernt werden kann).

System-Python

Sollte die Software der Distribution einfach mit dem site-packages-Verzeichnis der Distribution allein auf sys.path laufen und das site-packages des lokalen Systemadministrators sowie das benutzer-spezifische ignorieren? Das ist eine lohnenswerte Idee, und verschiedene Versionen davon kursieren schon seit einiger Zeit unter dem Namen „System Python“ oder „Plattform Python“ (mit einem separaten „Benutzer Python“ für Endbenutzer, die Python schreiben oder Python-Software getrennt vom System installieren). Es ist jedoch eine wesentlich komplexere Änderung. Erstens wäre es eine abwärts inkompatible Änderung. Wie im Abschnitt Motivation erwähnt, gibt es gültige Anwendungsfälle für die Ausführung von von der Distribution installierten Python-Anwendungen wie Sphinx oder Ansible mit lokal installierten Python-Bibliotheken, die auf ihrem sys.path verfügbar sind. Ein vollständiger Wechsel zum Ignorieren lokaler Pakete würde diese Anwendungsfälle brechen, und eine Distribution müsste eine Fall-zu-Fall-Analyse durchführen, ob eine Anwendung lokal installierte Bibliotheken sehen soll oder nicht.

Darüber hinaus hat Fedora versucht, diese Änderung vorzunehmen, und sie wieder rückgängig gemacht, und dabei ironischerweise festgestellt, dass ihre Implementierung der Änderung ihren Paketmanager beschädigt hat. Angesichts dieser Erfahrung gibt es eindeutig Details zu klären, bevor Distributoren diesen Ansatz zuverlässig implementieren können, und eine PEP, die ihn empfiehlt, wäre verfrüht.

Diese PEP ist als vollständige und in sich geschlossene Änderung gedacht, die unabhängig von der Entscheidung eines Distributors für oder gegen „System Python“ oder ähnliche Vorschläge ist. Sie ist nicht inkompatibel mit einer Distribution, die „System Python“ in Zukunft implementiert, und obwohl beide Vorschläge dieselbe Klasse von Problemen lösen, gibt es immer noch Argumente für die Implementierung von etwas wie „System Python“, selbst nachdem diese PEP implementiert wurde. Gleichzeitig versucht diese PEP jedoch ausdrücklich, eine gezieltere und minimalere Änderung vorzunehmen, so dass sie von Distributoren implementiert werden kann, die „System Python“ nicht einführen (oder nicht sofort einführen) wollen. Die Änderungen in dieser PEP stehen für sich allein und sind kein Zwischenschritt für einen zukünftigen Vorschlag. Diese PEP reduziert (aber eliminiert nicht) das Risiko, Systemsoftware zu beschädigen, während sie gleichzeitig *nicht* brechende Änderungen minimiert (aber nicht vollständig vermeidet), was daher viel einfacher zu implementieren sein sollte als die vollständige Idee von „System Python“, die die oben genannten Nachteile mit sich bringt.

Wir gehen davon aus, dass die Anleitungen in dieser PEP – dass Benutzer nach Möglichkeit virtuelle Umgebungen verwenden sollten und dass Distributoren getrennte sys.path-Verzeichnisse für von der Distribution verwaltete und lokal verwaltete Module haben sollten – zukünftige Experimente erleichtern werden. Dazu gehören die Verteilung von völlig separaten „System“- und „Benutzer“-Python-Interpretern, die Ausführung von Systemsoftware aus einer von der Distribution besessenen virtuellen Umgebung oder PYTHONHOME (aber die Bereitstellung eines einzigen Interpreters) oder die Änderung der Einstiegspunkte für bestimmte Software (wie den Paketmanager der Distribution), um einen sys.path zu verwenden, der nur von der Distribution verwaltete Verzeichnisse sieht. Diese Ideen selbst bleiben jedoch außerhalb des Rahmens dieser PEP.