Zusammenfassung

Dieses PEP schlägt vor, dass das Modul ensurepip, das durch PEP 453 in Python 3.4 eingeführt wurde, auf Python 2.7 zurückportiert wird. Es schlägt auch vor, die automatische Ausführung von ensurepip zu den Windows- und OSX-Installationen von Python 2.7 hinzuzufügen. Es schlägt jedoch nicht vor, die automatische Ausführung zum Makefile hinzuzufügen.

Es schlägt auch vor, die Dokumentationsänderungen für die Anleitungen zur Paketverteilung und -installation an die von 3.4 anzupassen, die die Verwendung des Moduls ensurepip zur Initialisierung des Installers erwähnt.

Begründung

Python 2.7 ist effektiv eine LTS-Version von Python, die das Ende der 2.x-Serie darstellt, und es gibt immer noch eine sehr große Anzahl von Benutzern, die Python 2.7 weiterhin als ihre Hauptversion verwenden. Diese Benutzer müssen manuell versuchen, den richtigen Weg zur Initialisierung der Paketierungswerkzeuge zu finden, um am breiteren Python-Ökosystem teilnehmen zu können.

Nach Meinung dieses PEP ist es aus 3 Hauptgründen wichtig, es Endbenutzern so einfach wie möglich zu machen, am breiteren Python-Ökosystem teilzunehmen:

1. Die Migration von Python 2.x auf 3.x hat eine Reihe von Schwierigkeiten, die durch eine Reihe von Drittanbieter-Modulen wie six [1], modernize [2] oder future [3] erleichtert werden. Die Verwendung dieser Werkzeuge erfordert jedoch, dass jeder, der das Projekt nutzt, ein Werkzeug zur Installation dieser Pakete hat.
2. Zusätzlich zu den Werkzeugen zur Unterstützung der Migration von Python 2.x auf 3.x gibt es auch eine Reihe von Modulen, die in Python 3 neu sind und für die Backports auf PyPI verfügbar sind. Dies kann auch die Fähigkeit von Personen erleichtern, 2.x- und 3.x-kompatible Software zu schreiben, und ihnen ermöglichen, einige der neueren Funktionen von Python 3 unter Python 2 zu nutzen.
3. Benutzer benötigen auch eine Reihe von Werkzeugen, um Python-Pakete zu erstellen, die den neueren vorgeschlagenen Standards entsprechen. Dinge wie setuptools [4], Wheel [5] und twine [6] ermöglichen eine sicherere, schnellere und zuverlässigere Toolchain für die Paketierung. Diese Werkzeuge können für Personen schwierig zu verwenden sein, wenn sie zuerst erfahren müssen, wie sie den Paketmanager installieren.
4. Eine der größten Stärken von Python ist das riesige Ökosystem von Bibliotheken und Projekten, die darauf aufgebaut sind und die meist über PyPI vertrieben werden. Um jedoch sinnvoll von diesem breiten Ökosystem profitieren zu können, müssen Endbenutzer, von denen einige neu sind, entscheiden, welchen Paketmanager sie erhalten möchten, wie sie ihn erhalten und ihn dann schließlich zuerst installieren.

Darüber hinaus erkennen alternative Implementierungen von Python die Vorteile von PEP 453, und sowohl PyPy als auch Jython planen, ensurepip in ihre 2.7-Laufzeitumgebungen zurückzuportieren.

Automatische Ausführung

PEP 453 hat ensurepip standardmäßig im Makefile und in den Windows- und OSX-Installationen automatisch ausgeführt. Dies ermöglichte es sicherzustellen, dass standardmäßig alle Benutzer Python mit bereits installiertem pip erhalten. Dieses PEP glaubt jedoch, dass dies zwar für die Windows- und Mac OS X-Installationen von Python 2.7 in Ordnung ist, aber für das Python 2.7 Makefile im Allgemeinen nicht in Ordnung ist.

Die Hauptverbraucher des Makefile sind nachgelagerte Paketmanager, die Python selbst verteilen. Diese nachgelagerten Distributoren möchten in der Regel nicht, dass pip über ensurepip installiert wird, und bevorzugen es, dass Endbenutzer es mit ihrem eigenen Paketmanager installieren. Wenn ensurepip nicht automatisch vom Makefile ausgeführt wird, können diese Distributoren einfach ignorieren, dass ensurepip zurückportiert wurde, und dennoch nicht mit pip erscheinen, das darüber installiert wurde.

Die Hauptverbraucher der OSX- und Windows-Installationen sind Endbenutzer, die versuchen, Python auf ihrem eigenen Computer zu installieren. Es gibt keinen Paketmanager, über den diese Benutzer pip über einen unterstützteren Mechanismus in ihre Python-Umgebung installieren können. Aus diesem Grund ist die Installation als Standard unter OSX und Windows nach Ansicht dieses PEP der beste Weg.

Dokumentation

Als Teil dieses PEP würden die aktualisierten Anleitungen zur Paketverteilung und -installation für Python 3.4 nach Python 2.7 zurückportiert.

Deaktivierung von ensurepip durch nachgelagerte Distributoren

Aufgrund seiner Verwendung im Modul venv können nachgelagerte Distributoren das Modul ensurepip in Python 3.4 nicht deaktivieren. Da Python 2.7 jedoch kein solches Modul hat, ist es nachgelagerten Distributoren ausdrücklich gestattet, das Modul ensurepip zu patchen, um dessen Installation zu verhindern.

Wenn ein nachgelagerter Distributor ensurepip in Python 2.7 vollständig deaktivieren möchte, sollte er das Modul zumindest bereitstellen und die Ausführung im Stil von python -m ensurepip zulassen. Es sollte jedoch Fehler auslösen oder anderweitig mit einem nicht-null-Exit-Code beenden und eine Fehlermeldung auf stderr ausgeben, die die Benutzer auf Alternativen zu ensurepip verweist.

Referenzen

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.