Verbesserung des Erlebnisses für neue Benutzer

Derzeit erfordert die Installation eines Drittanbieter-Python-Pakets in eine frisch installierte Python-Installation auf Systemen ohne plattformübergreifenden Paketmanager und Repository zunächst die Identifizierung eines geeigneten Paketmanagers und dessen Installation.

Selbst auf Systemen, die einen plattformübergreifenden Paketmanager haben, ist es unwahrscheinlich, dass dieser jedes Paket enthält, das im Python Package Index verfügbar ist, und selbst wenn ein gewünschtes Drittanbieter-Paket verfügbar ist, ist der korrekte Name im plattformübergreifenden Paketmanager möglicherweise nicht klar.

Das bedeutet, dass Benutzer, um effektiv mit dem Python Package Index-Ökosystem arbeiten zu können, wissen müssen, welcher Paketmanager zu installieren ist, wo er zu finden ist und wie er zu installieren ist. Dies hat zur Folge, dass Drittanbieter-Python-Projekte derzeit aus einer Vielzahl von unerwünschten Alternativen wählen müssen

• Annehmen, der Benutzer verfügt bereits über einen geeigneten plattformübergreifenden Paketmanager.
• Duplizieren Sie die Anweisungen und teilen Sie Ihren Benutzern mit, wie der Paketmanager installiert wird.
• Verzichten Sie vollständig auf Abhängigkeiten, um Installationsprobleme für Ihre Benutzer zu vereinfachen.

Alle diese verfügbaren Optionen haben erhebliche Nachteile.

Wenn ein Projekt einfach davon ausgeht, dass ein Benutzer bereits über die notwendigen Werkzeuge verfügt, können unerfahrene Benutzer eine verwirrende Fehlermeldung erhalten, wenn der Installationsbefehl nicht funktioniert. Einige Betriebssysteme können diesen Schmerz lindern, indem sie einen globalen Hook bereitstellen, der nach nicht existierenden Befehlen sucht und die Installation eines OS-Pakets vorschlägt, um den Befehl funktionsfähig zu machen. Dies funktioniert jedoch nur auf Systemen mit plattformübergreifenden Paketmanagern, die ein Paket enthalten, das den relevanten plattformübergreifenden Installer-Befehl bereitstellt (wie viele große Linux-Distributionen). Für Windows- und Mac OS X-Benutzer oder konservativere Linux-Distributionen ist keine solche Unterstützung verfügbar. Die Herausforderungen im Umgang mit diesem Problem für Anfänger (die oft auch völlig neu im Programmieren, der Verwendung von Kommandozeilen-Tools und der Bearbeitung von Systemumgebungsvariablen sind) sind ein regelmäßiges Feedback, das die Kern-Python-Entwickler von professionellen Pädagogen und anderen erhalten, die neuen Benutzern Python näherbringen.

Wenn ein Projekt sich entscheidet, die Installationsanweisungen zu duplizieren und seinen Benutzern mitzuteilen, wie der Paketmanager installiert wird, bevor es sein eigenes Projekt installiert, dann müssen diese Anweisungen jedes Mal von jedem Projekt aktualisiert werden, das sie dupliziert hat, wenn sie aktualisiert werden müssen. Dies ist besonders problematisch, wenn mehrere konkurrierende Installationstools verfügbar sind und verschiedene Projekte unterschiedliche Tools empfehlen.

Dieses spezifische Problem kann teilweise behoben werden, indem pip als Standard-Installer stark gefördert und anderen Projekten empfohlen wird, auf die eigenen Bootstrapping-Anweisungen von pip zu verweisen, anstatt sie zu duplizieren. Die Benutzererfahrung, die durch diesen Ansatz geschaffen wird, ist jedoch immer noch nicht besonders gut (obwohl Anstrengungen unternommen werden, einen kombinierten Windows-Installer für pip und seine Abhängigkeiten zu erstellen, was die Angelegenheiten auf dieser Plattform verbessern sollte, und Mac OS X und *nix-Plattformen im Allgemeinen wget und somit die Möglichkeit bieten, die Bootstrap-Skripte einfach von der Kommandozeile herunterzuladen und auszuführen).

Die Projekte, die sich entschieden haben, auf Abhängigkeiten vollständig zu verzichten, sind entweder gezwungen, die Bemühungen anderer Projekte zu duplizieren, indem sie eigene Lösungen für Probleme erfinden, oder sie müssen einfach andere Projekte in ihre eigenen Quellcodebäume aufnehmen. Beide Optionen bergen eigene Probleme, entweder durch duplizierte Wartungsarbeit im gesamten Ökosystem oder durch potenzielle Sicherheitslücken für Benutzer, da der enthaltene Code oder die duplizierten Bemühungen nicht automatisch aktualisiert werden, wenn eine neue Version veröffentlicht wird.

Durch die offizielle Empfehlung und Bereitstellung eines spezifischen plattformübergreifenden Paketmanagers wird es für Benutzer, die diese Drittanbieter-Pakete installieren möchten, sowie für die Distributoren einfacher, da sie nun sicher davon ausgehen können, dass die meisten Benutzer über die entsprechenden Installationstools verfügen (oder Zugang zu klaren Anweisungen, wie sie diese erhalten können). Dies wird in Zukunft voraussichtlich wichtiger werden, da das Wheel-Paketformat (absichtlich) keinen integrierten „Installer“ in Form von setup.py hat, so dass Benutzer, die aus einer Wheel-Datei installieren möchten, auch in den einfachsten Fällen einen Installer benötigen.

Die Reduzierung des Aufwands für die Installation eines Drittanbieter-Pakets sollte auch den Druck verringern, jedes nützliche Modul in die Standardbibliothek aufzunehmen. Dies ermöglicht es den Ergänzungen der Standardbibliothek, sich stärker darauf zu konzentrieren, warum Python ein bestimmtes Werkzeug von Haus aus benötigt und warum es vernünftig ist, dass dieses Paket den 18-24-monatigen Feature-Release-Zyklus der Standardbibliothek übernimmt, anstatt die allgemeine Schwierigkeit der Installation von Drittanbieter-Paketen als Rechtfertigung für die Aufnahme zu verwenden.

Die Bereitstellung eines standardmäßigen Installationssystems hilft auch beim Bootstrapping alternativer Build- und Installersysteme wie zc.buildout, hashdist und conda. Solange pip install <tool> funktioniert, bietet ein standardmäßiger Python-spezifischer Installer einen einigermaßen sicheren, plattformübergreifenden Mechanismus, um auf diese Dienstprogramme zuzugreifen.

Ermöglichung der Weiterentwicklung des breiteren Python-Packaging-Ökosystems

Da kein neuer Packaging-Standard ohne eine Übergangsstrategie, die die weit verbreiteten *aktuellen* Versionen von Python abdeckt (und nicht nur zukünftige Versionen, wie die meisten Sprachfunktionen), breite Akzeptanz finden kann, wird die in diesem PEP vorgeschlagene Änderung als notwendiger Schritt in der Weiterentwicklung des Python-Packaging-Ökosystems angesehen.

Die breitere Gemeinschaft hat den Python Package Index als Mechanismus für die Verteilung und Installation von Python-Software angenommen, aber die unterschiedlichen Belange der Sprachentwicklung und der sicheren Softwareverteilung bedeuten, dass ein schnellerer Feature-Release-Zyklus, der ältere Versionen umfasst, benötigt wird, um letztere richtig zu unterstützen.

Darüber hinaus hat das Kern-CPython-Entwicklungsteam den Luxus, die Unterstützung für frühere Python-Versionen lange vor dem Rest der Community einzustellen, da nachgelagerte kommerzielle Redistributoren die Aufgabe übernehmen, die Unterstützung für diese Versionen für Benutzer bereitzustellen, die sie immer noch benötigen, während viele Drittanbieter-Bibliotheken die Kompatibilität mit diesen Versionen beibehalten, solange sie weit verbreitet sind.

Dies bedeutet, dass das aktuelle Installationsmodell setup.py install für die Paketinstallation ernsthafte Schwierigkeiten für die Entwicklung und Einführung neuer Packaging-Standards darstellt, da je nachdem, wie ein Projekt seine setup.py-Datei schreibt, der Installationsbefehl (zusammen mit anderen Operationen) letztendlich das distutils-Paket der Standardbibliothek aufrufen kann.

Als Indikator dafür, wie dies zu Problemen für das breitere Ökosystem führen kann, betrachten Sie, dass die Feature-Reichweite von distutils in Python 2.6 im Juni 2008 (mit der Veröffentlichung von Python 2.6b1) eingefroren wurde, während die Feature-Reichweite von distutils in Python 2.7 im April 2010 (mit der Veröffentlichung von Python 2.7b1) eingefroren wurde.

Im Gegensatz dazu ermöglicht die Verwendung eines separaten Installer-Programms wie pip (das sicherstellt, dass selbst setup.py-Dateien, die distutils direkt aufrufen, die neuen Packaging-Standards unterstützen) die Unterstützung neuer Packaging-Standards in älteren Python-Versionen, indem einfach pip aktualisiert wird (das neue Feature-Releases etwa alle 6 Monate erhält). Die Situation bei älteren Python-Versionen wird weiter verbessert, indem Endbenutzern die Installation und Aktualisierung neuerer Build-Systeme wie setuptools oder verbesserter PyPI-Upload-Dienstprogramme wie twine erleichtert wird.

Es ist kein Zufall, dass dieses vorgeschlagene Modell der Verwendung eines separaten Installer-Programms mit mehr Metadaten und weniger aktiven Distributionsformaten dem entspricht, das von den meisten Betriebssystemen (einschließlich Windows seit der Einführung des Installerservices und des MSI-Dateiformats) sowie von vielen anderen sprachspezifischen Installern verwendet wird.

Für Python 2.6 beschränkt sich dieses Kompatibilitätsproblem weitgehend auf verschiedene Enterprise Linux-Distributionen (und ihre nachgelagerten Derivate). Diese Distributionen haben oft noch langsamere Update-Zyklen als CPython, sodass sie volle Unterstützung für Versionen von Python bieten, die als „nur Sicherheitsupdates“ im Upstream gelten (und manchmal sogar so weit gehen, dass das Kernentwicklungsteam sie nicht mehr unterstützt – Sie können immer noch kommerziellen Support für Python 2.3 erhalten, wenn Sie ihn wirklich benötigen!).

In der Praxis bedeutet die Tatsache, dass Tools wie wget und curl auf Linux-Systemen leicht verfügbar sind, dass die meisten Python-Benutzer unter Linux bereits mit der Kommandozeile vertraut sind und dass die meisten Linux-Distributionen mit einer Standardkonfiguration ausgeliefert werden, die die Ausführung von Python-Skripten erleichtert, dass die bestehenden pip-Bootstrapping-Anweisungen für jedes *nix-System bereits recht unkompliziert sind. Selbst wenn pip nicht vom Systempaketmanager bereitgestellt wird, ist die Verwendung von wget oder curl, um das Bootstrap-Skript von www.pip-installer.org abzurufen und es dann auszuführen, nur eine Reihe von Shell-Befehlen, die bei Bedarf einfach kopiert und eingefügt werden können.

Daher ist für jede Version von Python auf jedem *nix-System die Notwendigkeit, pip in älteren Versionen zu bootstrappen, keine größere Hürde für die Einführung neuer Packaging-Standards, da es nur eine weitere kleine Hürde für Benutzer dieser langlaufenden stabilen Releases darstellt. Für *nix-Systeme ist die formelle Bestätigung von pip als bevorzugtes Standard-Packaging-Tool wichtiger als die zugrundeliegenden technischen Details, die notwendig sind, um pip standardmäßig verfügbar zu machen, da dies die Art des Gesprächs zwischen den Entwicklern von pip und nachgelagerten Repackagern von sowohl pip als auch CPython verändert.

Für Python 2.7 hingegen ist das Kompatibilitätsproblem bei der Einführung neuer Metadatenstandards weitaus weiter verbreitet, da es die binären Installer von python.org für Windows und Mac OS X sowie sogar relativ schnelllebige *nix-Plattformen betrifft.

Erstens ist Python 2.7 im Gegensatz zu Python 2.6 immer noch eine voll unterstützte Upstream-Version und wird dies bis zur Veröffentlichung von Python 2.7.9 (derzeit für Mai 2015 geplant) bleiben. Zu diesem Zeitpunkt wird erwartet, dass es in den üblichen „nur Sicherheitsupdates“-Modus wechselt. Das bedeutet, dass es noch mindestens 19 Monate gibt, in denen Python 2.7 ein Ziel für die Bereitstellung von Python-Anwendungen ist, die die volle Upstream-Unterstützung genießen. Selbst nachdem das Kernentwicklungsteam 2.7 im Jahr 2015 auf den Modus „nur Sicherheitsupdates“ umstellt, wird Python 2.7 wahrscheinlich auch nach 2020 hinaus ein kommerziell unterstütztes Legacy-Ziel bleiben.

Während Python 3 bereits eine überzeugende Alternative zu Python 2 für neue Python-Anwendungen und -Bereitstellungen ohne bestehende Investitionen in Python 2 und ohne Abhängigkeit von spezifischen Python-2-only-Drittanbieter-Modulen (ein Set, das im Laufe der Zeit immer kleiner wird) darstellt, wird es länger dauern, überzeugende Geschäftsfälle für die Aktualisierung bestehender Python-2.7-basierter Infrastrukturen auf Python 3 zu schaffen, insbesondere in Situationen, in denen die Kultur des automatisierten Testens schwach ist (oder nicht vorhanden ist), was die effektive Nutzung der verfügbaren Migrationswerkzeuge erschwert.

Während dieser PEP nur Dokumentationsänderungen für Python 2.7 vorschlägt, wird, sobald pip über einen Windows-Installer verfügt, eine separate PEP erstellt und eingereicht, die die Erstellung und Verteilung von aggregierten Installern für zukünftige CPython 2.7-Wartungsversionen vorschlägt, die die CPython-, pip- und Python Launcher-for-Windows-Installer zu einem einzigen Download kombinieren (die separaten Downloads werden weiterhin verfügbar sein – die aggregierten Installer werden als Bequemlichkeit und als klare Angabe der empfohlenen Betriebsumgebung für Python unter Windows bereitgestellt).

Warum pip?

pip wurde als bevorzugter Standard-Installer gewählt, da es sich um ein bereits beliebtes Tool handelt, das mehrere Design- und Benutzererfahrungsprobleme seines Vorgängers easy_install löst (diese Probleme können aufgrund von Abwärtskompatibilitätsproblemen in easy_install selbst nicht ohne Weiteres behoben werden). pip ist auch gut geeignet, um innerhalb der Grenzen einer einzelnen Python-Runtime-Installation (einschließlich zugehöriger virtueller Umgebungen) zu arbeiten, was ein wünschenswertes Merkmal für ein mit CPython gebündeltes Tool ist.

Andere Tools wie zc.buildout und conda sind ambitionierter in ihren Zielen (und daher erheblich besser als pip bei der Handhabung von externen Binärabhängigkeiten), daher ist es sinnvoll, dass das Python-Ökosystem sie eher wie plattformübergreifende Paketmanager behandelt, mit denen sie interagieren können, anstatt als den Standard-plattformübergreifenden Installationswerkzeug. Diese Beziehung ähnelt der zwischen pip und plattformübergreifenden Paketmanagementsystemen wie apt und yum (die ebenfalls für die Handhabung beliebiger Binärabhängigkeiten ausgelegt sind).

Sicherheitsüberlegungen

Das in diesem PEP vorgesehene Design wurde bewusst gewählt, um keine wesentlichen Änderungen am Vertrauensmodell von CPython für Endbenutzer vorzunehmen, die nicht anschließend den Befehl pip install --upgrade pip ausführen.

Die Installer werden alle Komponenten einer voll funktionsfähigen Version von Python enthalten, einschließlich des pip-Installers. Der Installationsprozess erfordert keinen Netzwerkzugriff und verlässt sich nicht auf die Vertrauenswürdigkeit der Netzwerksicherheit zwischen pip und dem Python-Paketindex.

Nur Benutzer, die pip zur Kommunikation mit PyPI verwenden, müssen die zusätzlichen Sicherheitsüberlegungen beachten, die damit verbunden sind.

Das Kern-CPython-Team wird jedoch weiterhin bei der Überprüfung und Behebung des Zertifikatsupdate-Management-Problems helfen, das derzeit das requests-Projekt (und damit pip) betrifft, und kann auch bei der Behebung anderer identifizierter Sicherheitsprobleme Unterstützung anbieten [1].

Zuverlässigkeitsüberlegungen

Durch die Einbeziehung des Bootstraps als Teil der Standardbibliothek (anstatt ausschließlich als Feature der binären Installer) kann der korrekte Betrieb des Bootstrap-Befehls mit der bestehenden CPython-Buildbot-Infrastruktur einfach getestet werden, anstatt die Testlast für die Installer selbst erheblich zu erhöhen.

Implementierungsstrategie

Um sicherzustellen, dass bei der Installation von Python oder der Erstellung virtueller Umgebungen kein Netzwerkzugriff erforderlich ist, wird das ensurepip-Modul als Implementierungsdetail eine vollständige private Kopie von pip und seinen Abhängigkeiten enthalten, die verwendet wird, um pip zu extrahieren und in die Zielumgebung zu installieren. Es ist wichtig zu betonen, dass diese private Kopie von pip nur ein Implementierungsdetail ist und nicht auf die öffentlichen Fähigkeiten verlassen oder als vorhanden angesehen werden sollte, die durch das ensurepip-Modul (und indirekt durch venv) verfügbar gemacht werden.

Es gibt noch keine Referenzimplementierung für ensurepip. Das bestehende get-pip.py-Bootstrap-Skript demonstriert eine frühere Variante des allgemeinen Konzepts, aber die Version der Standardbibliothek würde die verbesserten Distributionsfähigkeiten der CPython-Installer nutzen, um private Kopien von pip und setuptools als Wheel-Dateien (anstatt als eingebettete Base64-kodierte Daten) zu enthalten und würde nicht versuchen, PyPI zu kontaktieren (sondern direkt von den privaten Wheel-Dateien installieren).

Anstatt separaten Code zur Handhabung des Bootstrapping einzubinden, wird das ensurepip-Modul sys.path entsprechend manipulieren, um die Verwendung der Wheel-Dateien zur Installation selbst zu ermöglichen, entweder in der aktuellen Python-Installation oder in einer virtuellen Umgebung (wie durch die an den Bootstrap-Befehl übergebenen Optionen bestimmt).

Es wird vorgeschlagen, die Implementierung in fünf separaten Schritten durchzuführen (alle Schritte nach den ersten beiden sind unabhängig voneinander und können in beliebiger Reihenfolge durchgeführt werden)

• Der erste Schritt würde die Dokumentation „Installing Python Modules“ aktualisieren, um die Verwendung von pip zu empfehlen und auf die Anweisungen des pip-Teams zum Herunterladen und Installieren zu verweisen. Diese Änderung würde auf Python 2.7, 3.3 und 3.4 angewendet werden.
• Das Modul ensurepip und die privaten Kopien der aktuellsten Versionen von pip und setuptools würden zu Python 3.4 hinzugefügt und die Dokumentation „Installing Python Modules“ für 3.4 entsprechend aktualisiert werden.
• Das CPython Windows-Installer würde aktualisiert, um die neue pip-Installationsoption für Python 3.4 anzubieten.
• Das CPython Mac OS X-Installer würde aktualisiert, um die neue pip-Installationsoption für Python 3.4 anzubieten.
• Das Modul venv und der Befehl pyvenv würden aktualisiert, um ensurepip in Python 3.4 zu verwenden.
• Die PATH-Handhabung unter Windows würde für Python 3.4+ aktualisiert.

Integrationszeitplan

Wenn dieser PEP akzeptiert wird, ist der geplante Zeitrahmen für die Integration von pip in die CPython-Veröffentlichung wie folgt:

• so bald wie möglich nach der Veröffentlichung von 3.4.0 alpha 4
  • Dokumentation aktualisiert und ensurepip implementiert basierend auf einer Vorabversion von pip 1.5.
  • Alle anderen vorgeschlagenen Funktionsänderungen für Python 3.4 implementiert, einschließlich der Installer-Updates zur Aufrufung von ensurepip.
• bis zum 20. November (3 Tage vor dem geplanten Datum von 3.4.0 beta 1)
  • ensurepip aktualisiert, um einen pip 1.5 Release Candidate zu verwenden.
  • PEP 101 aktualisiert, um sicherzustellen, dass die gebündelte Version von pip auf dem neuesten Stand ist.
• bis zum 24. November (geplantes Datum von 3.4.0 beta 1)
  • Wie bei jeder neuen Funktion müssen alle vorgeschlagenen Funktionsänderungen für Python 3.4 vor dem Feature-Freeze für Beta-Versionen implementiert werden.
• bis zum 29. Dezember (1 Woche vor dem geplanten Datum von 3.4.0 beta 2)
  • Problem mit dem Zertifikatsmanagement von requests behoben
  • ensurepip aktualisiert auf die endgültige Version von pip 1.5 oder eine nachfolgende Wartungsversion (einschließlich einer entsprechend aktualisierten, gebündelten Kopie von requests).

(Siehe PEP 429 für die aktuellen offiziellen geplanten Daten jeder Veröffentlichung. Die oben genannten Daten sind aktuell ab dem 20. Oktober 2013.)

Wenn bis eine Woche vor der geplanten Veröffentlichung von Python 3.4 Beta 2 keine finale oder Wartungs-Release von pip 1.5 mit einer geeignet aktualisierten Version von requests verfügbar ist, dann wird die Implementierung dieses PEP auf Python 3.5 verschoben. Es ist unwahrscheinlich, dass dieses Szenario eintritt – das vorläufige Datum für die pip 1.5 Release ist derzeit der 1. Dezember.

In zukünftigen CPython-Releases ist diese Art von koordinierter Zeitplanung nicht mehr erforderlich: Der CPython Release Manager kann einfach auf die neueste veröffentlichte Version von pip aktualisieren. In diesem Fall sind jedoch einige Korrekturen in pip erforderlich, damit das Bündeln korrekt funktioniert, und der Zertifikatsaktualisierungsmechanismus für requests muss verbessert werden, daher muss der pip 1.5 Release-Zyklus ordnungsgemäß mit den CPython 3.4 Beta-Releases abgestimmt werden.

Vorgeschlagene CLI

Die vorgeschlagene CLI basiert auf einer Teilmenge der bestehenden pip install Optionen

Usage:
  python -m ensurepip [options]

General Options:
  -h, --help          Show help.
  -v, --verbose       Give more output. Option is additive, and can be used up to 3 times.
  -V, --version       Show the pip version that would be extracted and exit.
  -q, --quiet         Give less output.

Installation Options:
  -U, --upgrade       Upgrade pip and dependencies, even if already installed
  --user              Install using the user scheme.
  --root <dir>        Install everything relative to this alternate root directory.

In den meisten Fällen müssen Endbenutzer diese CLI nicht direkt verwenden, da pip automatisch bei der Installation von Python oder beim Erstellen einer virtuellen Umgebung installiert wurde. Sie ist jedoch formell als öffentliche Schnittstelle dokumentiert, um mindestens die folgenden bekannten Anwendungsfälle zu unterstützen

• Windows- und Mac OS X-Installationen, bei denen die Option „pip installieren“ während der Installation nicht ausgewählt wurde
• Jede Installation, bei der der Benutzer zuvor „pip uninstall pip“ ausgeführt hat

Benutzer, die die neueste Version von PyPI abrufen möchten oder mehr Flexibilität benötigen, können das extrahierte pip entsprechend aufrufen.

Vorgeschlagene Modul-API

Die vorgeschlagene ensurepip Modul-API besteht aus den folgenden beiden Funktionen

def version():
    """
    Returns a string specifying the bundled version of pip.
    """

def bootstrap(root=None, upgrade=False, user=False, verbosity=0):
    """
    Bootstrap pip into the current Python installation (or the given root
    directory).
    """

Aufruf aus den CPython-Installationsprogrammen

Die CPython Windows- und Mac OS X-Installer erhalten jeweils eine neue Option

• pip (das Standard-Paketverwaltungsdienstprogramm für Python) installieren?

Diese Option ist standardmäßig aktiviert.

Wenn die Option aktiviert ist, ruft das Installationsprogramm den folgenden Befehl mit dem gerade installierten Python auf

python -m ensurepip --upgrade

Dies stellt sicher, dass die Installation oder Aktualisierung von CPython standardmäßig sicherstellt, dass die installierte Version von pip mindestens so aktuell ist wie die, die mit dieser Version von CPython geliefert wird. Wenn bereits eine neuere Version von pip installiert wurde, gibt python -m ensurepip --upgrade einfach zurück, ohne etwas zu tun.

Installation aus dem Quellcode

So wie die vorcompilierten binären Installer standardmäßig mit python -m ensurepip aktualisiert werden, wird eine ähnliche Änderung an den Befehlen make install und make altinstall der Quellverteilung vorgenommen. Die Verzeichniseinstellungen im sysconfig Modul sollten sicherstellen, dass die pip-Komponenten automatisch an den erwarteten Orten installiert werden.

ensurepip selbst (einschließlich der privaten Kopie von pip und seiner Abhängigkeiten) wird immer normal installiert (da es ein regulärer Bestandteil der Standardbibliothek ist), aber es wird eine Option bereitgestellt, um die Ausführung von ensurepip zu überspringen.

Das bedeutet, dass selbst die Installation aus Quellen standardmäßig pip bereitstellt, aber Anbieter, die pip über andere Mittel bereitstellen (oder es gar nicht bereitstellen), immer noch die Möglichkeit haben, die Installation mit ensurepip zu überspringen.

Änderungen an virtuellen Umgebungen

Python 3.3 enthielt einen Standardbibliotheksansatz für virtuelle Python-Umgebungen über das venv-Modul. Seit seiner Veröffentlichung ist klar geworden, dass nur sehr wenige Benutzer bereit waren, diese Funktion direkt zu nutzen, teilweise aufgrund des Fehlens eines standardmäßig installierten Installers in der virtuellen Umgebung. Sie haben stattdessen weiterhin das Paket virtualenv verwendet, das pip standardmäßig installiert hat.

Um das venv für Benutzer nützlicher zu machen, wird es so geändert, dass es beim Erstellen der neuen Umgebung standardmäßig den Pip-Bootstrap ausführt. Dies gibt den Benutzern die gleiche Bequemlichkeit innerhalb der virtuellen Umgebung wie dieser PEP außerhalb davon bietet, und bringt das venv-Modul näher an die Funktionsgleichheit mit dem externen virtualenv-Paket heran, was es zu einem geeigneteren Ersatz macht.

Um Fälle zu behandeln, in denen ein Benutzer kein Pip in seine virtuelle Umgebung bootstrappen möchte, wird eine Option --without-pip hinzugefügt.

Die APIs venv.EnvBuilder und venv.create werden aktualisiert, um einen neuen Parameter zu akzeptieren: with_pip (standardmäßig False).

Der neue Standard für die Modul-API wird aus Kompatibilitätsgründen mit dem aktuellen Verhalten gewählt (da angenommen wird, dass die meisten Aufrufe des venv-Moduls über Drittanbieter-Tools erfolgen, die wahrscheinlich nicht möchten, dass pip ohne explizite Anforderung installiert wird), während der Standard für die Kommandozeilenschnittstelle gewählt wird, um sicherzustellen, dass pip in den meisten virtuellen Umgebungen ohne zusätzliche Maßnahmen seitens des Endbenutzers verfügbar ist.

Da diese Änderung nur Python 3.4 und spätere Versionen betreffen wird, wird das Drittanbieter-Projekt virtualenv weiterhin benötigt, um eine konsistente Cross-Version-Erfahrung in Python 3.3 und 2.7 zu erhalten.

Dokumentation

Der Abschnitt „Installing Python Modules“ der Dokumentation der Standardbibliothek in Python 2.7, 3.3 und 3.4 wird aktualisiert, um die Verwendung des pip-Installers zu empfehlen, entweder standardmäßig in Python 3.4 bereitgestellt oder vom Benutzer in Python 2.7 oder 3.3 abgerufen und installiert. Er enthält eine kurze Beschreibung der gebräuchlichsten Befehle und Optionen, verweist aber für die vollständigen Details auf die extern gepflegte pip-Dokumentation.

In Python 3.4 werden auch die Dokumentationen von pyvenv und venv aktualisiert, um auf den überarbeiteten Leitfaden zur Modulinstallation zu verweisen.

Der vorhandene Inhalt des Leitfadens zur Modulinstallation wird in allen Versionen beibehalten, jedoch unter einer neuen Unterüberschrift „Invoking distutils directly“.

Bundling von CA-Zertifikaten mit CPython

Die Implementierung von ensurepip wird den pip CA-Bundle zusammen mit dem Rest von pip enthalten. Das bedeutet, dass CPython effektiv ein CA-Bundle enthält, das ausschließlich von pip verwendet wird, nachdem es extrahiert wurde.

Dies wird als vorzuziehen gegenüber dem alleinigen Verlassen auf die Zertifikatsspeicher des Systems angesehen, da es sicherstellt, dass pip über alle unterstützten Python-Versionen hinweg gleich funktioniert, auch über die von Python 3.4 hinaus, die auf Windows nicht auf den Zertifikatsspeicher des Systems zugreifen können.

Automatische Installation von setuptools

pip ist derzeit von setuptools abhängig, um die Metadatengenerierung während des Build-Prozesses zu handhaben, sowie einige andere Funktionen. Obwohl daran gearbeitet wird, diese Abhängigkeit zu reduzieren oder zu eliminieren, ist nicht klar, ob diese Arbeit für pip 1.5 abgeschlossen sein wird (was die Version ist, die wahrscheinlich aktuell ist, wenn Python 3.4.0 veröffentlicht wird).

Dieses PEP schlägt vor, dass, falls pip es immer noch als Abhängigkeit benötigt, ensurepip eine private Kopie von setuptools (zusätzlich zur privaten Kopie von ensurepip) enthalten wird. python -m ensurepip wird dann die private Kopie installieren, zusätzlich zur Installation von pip selbst.

Dieses Verhalten wird jedoch offiziell als Implementierungsdetail betrachtet. Andere Projekte, die explizit setuptools benötigen, müssen weiterhin eine entsprechende Abhängigkeitserklärung bereitstellen, anstatt davon auszugehen, dass setuptools immer zusammen mit pip installiert wird.

Die private Kopie von setuptools wird aus ensurepip entfernt, sobald sie nicht mehr benötigt wird. Dies wird voraussichtlich der Zeitpunkt sein, an dem get-pip.py aufhört, setuptools standardmäßig zu installieren. Solange setuptools benötigt wird, wird es eine völlig unveränderte Kopie der neuesten Upstream-Setuptools-Version sein, einschließlich des easy_install-Skripts, wenn das Upstream-Setuptools es weiterhin enthält. Die Installation von easy_install zusammen mit pip wird nicht als wünschenswert erachtet, aber die Installation eines fehlerhaften setuptools wäre schlimmer. Dieses Problem wird sich natürlich auflösen, sobald die pip-Entwickler ihre Abhängigkeit von setuptools beseitigt haben und die private Kopie von setuptools vollständig aus CPython entfernt werden kann.

Aktualisierung der privaten Kopie von pip

Um mit den Entwicklungen im Packaging Schritt zu halten und den Benutzern eine möglichst aktuelle Version zur Verfügung zu stellen, wird das ensurepip-Modul regelmäßig auf die neuesten Versionen aller von ihm gebootstrappten Komponenten aktualisiert.

Nach jeder neuen pip-Veröffentlichung und erneut während der Vorbereitung jeder Python-Veröffentlichung (einschließlich Feature-Releases) wird ein Skript, das Teil der Implementierung dieses PEP ist, ausgeführt, um sicherzustellen, dass die privaten Kopien im CPython-Quellcode-Repository auf die neuesten Versionen aktualisiert wurden.

Aktualisierung der ensurepip-Modul-API und CLI

Wie venv und pyvenv unterliegt die ensurepip-Modul-API und CLI den normalen Regeln für die Standardbibliothek: Keine neuen Funktionen sind in Wartungs-Releases erlaubt.

Die eingebetteten Komponenten können jedoch wie oben erwähnt aktualisiert werden, sodass das extrahierte pip in Wartungs-Releases zusätzliche Funktionalität bieten kann.

Abwärtskompatibilität

Die öffentliche API und CLI des ensurepip-Moduls selbst unterliegen der üblichen Rückwärtskompatibilitätsrichtlinie von Python für seine Standardbibliothek. Die extern entwickelte Software, die dieses PEP bündelt, tut dies nicht.

Am wichtigsten ist, dass dies bedeutet, dass die gebootstrappte Version von pip in CPython-Wartungs-Releases neue Funktionen erhalten kann und pip seinem eigenen 6-Monats-Release-Zyklus anstelle des 18-24-monatigen CPython-Zyklus folgt.

Sicherheitsupdates

Jede Sicherheitsaktualisierung, die das ensurepip-Modul betrifft, wird vor der Veröffentlichung mit dem Python Security Response Team (security@python.org) geteilt. Das PSRT wird dann entscheiden, ob das gemeldete Problem eine Sicherheitsveröffentlichung von CPython mit einer aktualisierten privaten Kopie von pip rechtfertigt.

Lizenzierung

pip ist derzeit unter 1 Clause BSD lizenziert und enthält Code aus anderen Projekten. Zusätzlich wird dieses PEP setuptools enthalten, bis pip es nicht mehr benötigt. Die Lizenzen hierfür finden Sie in der folgenden Tabelle.

Alle diese Lizenzen sollten mit der PSF-Lizenz kompatibel sein. Zusätzlich ist unklar, ob ein CA-Bundle urheberrechtlich schützbares Material ist und ob es daher lizenziert werden muss oder kann.

Änderung des Namens des Skriptverzeichnisses unter Windows

Frühere Versionen dieses PEP schlugen vor, den Namen des Skriptinstallationsverzeichnisses unter Windows von „Scripts“ in „bin“ zu ändern, um die plattformübergreifende Konsistenz der von pyvenv erstellten virtuellen Umgebungen zu verbessern.

Paul Moore stellte jedoch fest, dass diese Änderung wahrscheinlich nicht abwärtskompatibel mit plattformübergreifenden Windows-Installern war, die mit früheren Python-Versionen erstellt wurden, daher wurde die Änderung aus diesem PEP entfernt [2].

Einbeziehung von ensurepip in Python 2.7 und 3.3

Frühere Versionen dieses PEP argumentierten, dass die Herausforderungen bei der Bootstrappung von pip für neue Benutzer eine so erhebliche Barriere für das zukünftige Wachstum von Python darstellten, dass sie die Aufnahme von ensurepip als neues Feature in den kommenden Wartungs-Releases von Python 2.7 und 3.3 rechtfertigte.

Während der Vorschlag, pip mit Python 3.4 bereitzustellen, universell beliebt war, war dieser Teil des Vorschlags sehr umstritten und wurde schließlich von MvL als BDFL-Delegate abgelehnt.

Dementsprechend wurde der Vorschlag, ensurepip auf Python 2.7 und 3.3 zurückzuportieren, aus diesem PEP entfernt, zugunsten der Erstellung eines Windows-Installers für pip und eines möglichen zukünftigen PEP, das die Erstellung eines aggregierten Installers für Python 2.7 vorschlägt, der CPython 2.7, pip und den Python Launcher für Windows kombiniert.

Automatische Kontaktaufnahme mit PyPI beim Bootstrapping von pip

Frühere Versionen dieses PEP nannten das Bootstrapping-Modul getpip und luden standardmäßig pip von PyPI herunter und installierten es, wobei die private Kopie nur als Fallback-Option oder bei expliziter Anforderung verwendet wurde.

Dies führte zu mehreren komplexen Ausnahmefällen, zusammen mit Schwierigkeiten bei der Definition einer sauberen API und CLI für das Bootstrap-Modul. Es änderte auch erheblich das Standard-Vertrauensmodell für die binären Installer, die auf python.org veröffentlicht wurden, da Endbenutzer ausdrücklich vom Vertrauen in die Sicherheit des PyPI-Ökosystems **absehen** müssten (anstatt sich dafür zu entscheiden, indem sie nach der Installation ausdrücklich pip aufrufen).

Daher wurde das PEP zu dem aktuellen Design vereinfacht, bei dem der Bootstrap **immer** die private Kopie von pip verwendet. Die Kontaktaufnahme mit PyPI ist nun immer ein expliziter separater Schritt, mit direktem Zugriff auf die vollständige pip-Schnittstelle.

Das Entfernen des impliziten Versuchs, auf PyPI zuzugreifen, machte es auch möglich, ensurepip standardmäßig aufzurufen, wenn von einer benutzerdefinierten Quell-Build-Installation aus installiert wird.

Implizites Bootstrap

PEP 439, der Vorgänger dieses PEP, schlägt seine eigene Lösung vor. Seine Lösung beinhaltet das Ausliefern eines gefälschten pip-Befehls, der, wenn er ausgeführt wird, implizit pip bootstrappt und installiert, wenn es noch nicht existiert. Dies wurde abgelehnt, weil es zu „magisch“ ist. Es verbirgt dem Endbenutzer, wann genau der pip-Befehl installiert wird oder dass er überhaupt installiert wird. Es gibt auch keine Empfehlungen oder Überlegungen an nachgelagerte Paketierer, die den global installierten pip über die für ihr System typischen Mechanismen verwalten möchten.

Der implizite Bootstrap-Mechanismus stieß auch auf mögliche Berechtigungsprobleme, wenn ein Benutzer versehentlich versuchte, pip zu bootstrappen, ohne Schreibzugriff auf die entsprechenden Installationsverzeichnisse zu haben.

Einbeziehung von pip direkt in die Standardbibliothek

Ähnlich wie dieses PEP ist der Vorschlag, pip einfach in die Standardbibliothek aufzunehmen. Dies würde sicherstellen, dass Python pip immer enthält und alle Probleme für Endbenutzer löst, die nicht über pip standardmäßig verfügen. Dies wurde abgelehnt, da wir aus der Einbeziehung und Geschichte von distutils in die Standardbibliothek gelernt haben, dass der Verlust der Fähigkeit, die Packaging-Tools unabhängig zu aktualisieren, die Tools in einem Zustand ständigen Schwebezustands zurücklassen kann. Es macht sie unfähig, sich jemals in einem Zeitrahmen vernünftig zu entwickeln, der die Benutzer tatsächlich betrifft, da neue Funktionen nicht für die breite Bevölkerung für *Jahre* verfügbar sein werden.

Die Ermöglichung der separaten Weiterentwicklung der Packaging-Tools unabhängig von den Release- und Adoptionsplänen von Python ermöglicht es, dass die Verbesserungen von *allen* Mitgliedern der Python-Community genutzt werden können und nicht nur von denen, die auf der Schneide von Python-Releases leben können.

Es gab in der Vergangenheit auch Probleme mit dem „Dual Maintenance“-Problem, wenn ein Projekt weiterhin extern gepflegt wird, während auch ein Fork in der Standardbibliothek gepflegt wird. Da die externe Wartung von pip zur Unterstützung früherer Python-Versionen immer erforderlich sein wird, wird der vorgeschlagene Bootstrapping-Mechanismus zur expliziten Verantwortung der CPython-Kernentwickler (unterstützt von den pip-Entwicklern) gemacht, während pip-Probleme, die im CPython-Tracker gemeldet werden, zum pip-Issue-Tracker migriert werden. Es wird zweifellos immer noch einige Verwirrung bei den Benutzern geben, welcher Tracker verwendet werden soll, aber hoffentlich weniger als in der Vergangenheit, als vollständige öffentliche Kopien von Drittanbieterprojekten in die Standardbibliothek aufgenommen wurden.

Der in diesem PEP beschriebene Ansatz vermeidet auch einige technische Probleme im Zusammenhang mit der Handhabung von CPython-Wartungsaktualisierungen, wenn pip unabhängig zu einer neueren Version aktualisiert wurde. Der vorgeschlagene pip-basierte Bootstrapping-Mechanismus handhabt dies automatisch, da pip und der Systeminstaller niemals darum kämpfen, wer für die pip-Installation zuständig ist (sie wird immer über pip verwaltet, entweder direkt oder indirekt über das ensurepip-Bootstrap-Modul).

Schließlich ermöglicht der separate Bootstrapping-Schritt auch, dass pip überhaupt nicht installiert wird, wenn Endbenutzer dies wünschen. Dies ist oft der Fall, wenn Integratoren Systempakete verwenden, um die Installation von Komponenten zu handhaben, die in mehreren Sprachen mit einem gemeinsamen Werkzeugsatz geschrieben sind.

Standardmäßig –user-Installation

Es wurde erwogen, pip standardmäßig in das Verzeichnis `per-user site-packages` zu bootstrappen. Dieses Verhalten wäre jedoch überraschend (da es vom Standardverhalten von pip selbst abweicht) und gilt derzeit auch nicht als zuverlässig (es gibt einige Randfälle, die nicht korrekt behandelt werden, wenn pip in das Benutzer-Site-Packages-Verzeichnis anstelle des System-Site-Packages installiert wird).