Hinweis für den Leser

Dieses Dokument ist ein detaillierter *Vorschlag*, der dazu dient, bei einer "Zustimmungs-" oder "Ablehnungs-"Entscheidung über den Ersatz der bestehenden Installationsformate für Python unter Windows durch ein neues Format zu helfen. Es ist nicht als bindende Spezifikation gedacht, noch ist es Benutzerdokumentation oder eine Interoperabilitätsspezifikation. Die tatsächliche Implementierung kann im Laufe der Zeit variieren, wenn sich Bedürfnisse ändern, und dies ist nicht als "Verstoß" gegen dieses PEP zu betrachten. Alle für die öffentliche Nutzung bestimmten Schnittstellen und Protokolle werden unabhängig dokumentiert und gemäß den Standardfristen für die Veralterung gepflegt.

Dokumentation zur Installation von Python unter Windows finden Sie unter docs.python.org/using/windows.html.

Erwartungen

Basierend auf erheblicher anekdotischer Erfahrung und der Analyse verfügbarer quantitativer Daten (obwohl nicht unbedingt öffentlich) stellen wir folgende Behauptungen über die Mehrheit der Python-Benutzer unter Windows auf:

• Die meisten Benutzer möchten die neueste stabile Version
• Die meisten Benutzer möchten eine "Ein-Klick"-Installation (oder weniger Klicks)
• Die meisten Benutzer möchten keine Administratorrechte verwenden
• Die meisten Benutzer profitieren von der Installation von Wartungsaktualisierungen
• Die meisten Benutzer erwarten, dass der python-Befehl nach der Installation funktioniert

Die wichtigste Unterstützung für diese Behauptungen ist, dass die beliebtesten Installer, die von den Benutzern aktiv gewählt werden, die neueste stabile Version auf python.org und die neueste stabile Version im Windows Store sind, die beide diese Anforderungen erfüllen.

Wir stellen folgende Annahmen über andere signifikante Benutzergruppen auf. Diese können einige Überschneidungen zwischen den Gruppen haben, und zumindest einige Benutzer erwarten alle davon.

• Einige Benutzer möchten Python programmatisch installieren
• Einige Benutzer möchten eine bestimmte Version installieren
• Einige Benutzer möchten viele Versionen installieren
• Einige Benutzer möchten für alle Benutzer ihres Rechners installieren
• Einige Benutzer möchten keine Startmenü-Verknüpfungen
• Einige Benutzer möchten als Teil des Build-Prozesses ihres Projekts installieren
• Einige Benutzer möchten als Teil des Installationsprozesses ihres Projekts installieren
• Einige Benutzer beabsichtigen, ihre Installation niemals zu aktualisieren
• Einige Benutzer erwarten, dass der py-Befehl nach der Installation funktioniert

Diese Annahmen haben sich im Laufe der Zeit als existent erwiesen, obwohl ihre relative Bedeutung nicht quantifiziert wurde. Die NuGet-Pakete und die einbettbare Distribution können die meisten dieser Bedürfnisse erfüllen.

Traditioneller Installer

Der traditionelle Installer ist eine ausführbare Datei, die direkt von python.org heruntergeladen werden kann und das gesamte Entwicklungskit für Python installiert. Dies umfasst den CPython-Interpreter, die Standardbibliothek, Python-Header und Importbibliotheken, Builds von Tcl und Tk, die Dokumentation als HTML-Dateien, die Laufzeit- und Standardbibliotheks-Testsuite, Startmenü-Verknüpfungen für Python und IDLE, Debug-Symbole und Debug-Builds der Binärdateien, den py.exe-Launcher und seine Dateizuordnungen sowie Funktionen zur Modifizierung der PATH-Umgebungsvariablen des Benutzers, zur Aktivierung der Langpfadunterstützung auf ihrem System, zur Vorabgenerierung von .pyc-Dateien für die Standardbibliothek und zur Installation von pip. Ab 3.13 enthält er auch eine Reihe experimenteller freigetheradeter Binärdateien. Viele dieser Komponenten sind optional.

Nach dem Herunterladen der ausführbaren Datei werden den Benutzern eine "Schnellinstallations"-Option präsentiert, die in ihrem Benutzerverzeichnis mit den meisten aktivierten Optionen installiert wird. Wir glauben, dass die meisten Benutzer diese Option wählen.

Eine zweite Option neben der Schnellinstallation führt den Benutzer zu zwei Seiten mit Optionen, die die zu installierenden Komponenten sowie andere Optionen wie das Installationsverzeichnis und die Frage, ob für alle Benutzer installiert werden soll, auflistet.

All diese Optionen können über die Befehlszeile angegeben werden, und es gibt auch eine Option, die Installation ohne Anzeige einer Benutzeroberfläche fortzusetzen. Basierend auf Feedback und Fehlerberichten werden all diese Optionen von mindestens einigen Benutzern verwendet. Da wir jedoch keine Installations-Telemetrie verfolgen, haben wir keine Möglichkeit zu wissen, welche Optionen wichtiger sind als andere.

Hinter den Kulissen ist der traditionelle Installer ein Burn-Bundle, das mit dem Wix Toolset Installer Framework generiert wird und eine oder mehrere MSI-Dateien für jede Funktion enthält. Dieses Framework wird extensiv von Microsoft selbst genutzt und bietet die direkteste Methode zur Verwendung von Windows Installer. Das Bundle ist eine benutzerdefinierte C++-Anwendung, die auf ihrer Vorlage basiert und es uns ermöglicht, das Gesamtverhalten des Installers anzupassen, um genau zu bestimmen, welche MSI-Dateien tatsächlich installiert werden sollen. Der Prozess des Kopierens von Dateien, des Aktualisierens der Registrierung und des Generierens von Verknüpfungen wird vollständig von Windows Installer gehandhabt.

Neben den beabsichtigten Verwendungszwecken ist bekannt, dass viele Benutzer den traditionellen Installer für andere Szenarien verwenden werden (oder versuchen werden), wie z. B. nicht registrierte Installationen und automatisierte CI-Systeminstallationen. Obwohl bessere Alternativen verfügbar sind, sind sie nicht so offensichtlich, und die Hoffnung ist, dass ein zukünftiges Design diese Szenarien erleichtern würde.

Windows Store

Die Windows Store-Pakete für CPython werden als Teil unseres normalen Release-Prozesses mit nahezu identischen Binärdateien wie die anderen Pakete erstellt. Aufgrund der Tatsache, dass sie sich in einem App-Store-Paket befinden, ist die primäre python.exe so erweitert, dass sie ihren Speicherort korrekt bestimmen kann, und alternative pip.exe und andere Verknüpfungen sind enthalten, um den Mangel an PATH-Umgebungsvariablen-Einstellungen auszugleichen. Diese werden in PC\python_uwp.cpp in unserem Repository implementiert.

Diese Pakete werden installiert, indem nach Python im Microsoft Store gesucht wird, was Ergebnisse für jede Hauptversion seit 3.8 findet. Benutzer müssen dann eine Version auswählen und sie installieren. Diese Pakete enthalten den CPython-Interpreter, die Standardbibliothek, Tcl/Tk, IDLE und pip und erstellen Dateizuordnungen, Startmenü-Verknüpfungen und globale Befehle für python.exe, python3.exe, python3.X.exe, pip[3[.X]].exe und idle[3[.X]].exe. Es ist keine PATH-Modifikation möglich oder erforderlich, obwohl Benutzer ihre globalen Verknüpfungen über die Einstellungsseite "App-Ausführungsaliase verwalten" verwalten müssen.

Darüber hinaus hat Microsoft auf einer sauberen Windows-Installation einen Standardbefehl python.exe hinzugefügt. Dieser fängt Versuche von Benutzern ab, Python auf einem Rechner zu starten, der es noch nicht installiert hat. Wenn der Befehl direkt aufgerufen wird, öffnet er die Microsoft Store-App auf der Seite mit der empfohlenen Python-App, typischerweise der neuesten Version. Diese App wird vollständig von Microsoft gesteuert. Basierend auf Telemetriedaten, die mit der Python-App verknüpft sind (die vom Upstream-Python-Projekt gesteuert wird), kommen etwa 300.000 Installationen pro Monat über diesen Redirector, was etwa 90 % der Gesamtinstallationen dieser Version ausmacht.

Hinter den Kulissen basiert das Store-Paket auf Microsofts neuer Installer-Technologie für Apps, bekannt als APPX oder MSIX. Dies sind im Wesentlichen reine ZIP-Dateien mit einer geringen Menge an Metadaten, mit der Ausnahme, dass die Installation vom Betriebssystem gehandhabt wird. Sie werden immer an einem festen Speicherort extrahiert, der für alle Benutzer zugänglich, aber von keinem modifizierbar ist, und automatisch auf die neueste Version aktualisiert. Die eigenen Daten des Benutzers werden an einem vom Betriebssystem verwalteten Speicherort in seinem Benutzerprofil gespeichert und können mit regulären Betriebssystemfunktionen zurückgesetzt, gesichert und wiederhergestellt werden.

NuGet-Paket

Die NuGet-Pakete für CPython werden als Teil unseres normalen Release-Prozesses erstellt und veröffentlicht. Der Inhalt ist identisch mit dem traditionellen Installer. Ein NuGet-Paket wird auf nuget.org veröffentlicht, einem Paketmanager, der typischerweise mit .NET-Sprachen verbunden ist, aber stark in jedes von Visual Studio unterstützte Projekt integriert ist. Dies macht es zu einem guten Format für Benutzer, die eine leichtgewichtige Python-Installation als Teil ihres regulären Build-Prozesses wünschen und Einbettungsszenarien vereinfachen können.

Die Pakete werden mit jedem Tool installiert, das die NuGet-API verwenden kann, oder können direkt heruntergeladen werden, sobald die URL des Pakets bekannt ist. Das Paket ist eine reine ZIP-Datei mit einigen Metadaten. Es enthält den CPython-Interpreter, die Standardbibliothek, Entwicklungsheader und Importbibliotheken sowie pip. Es führt zur Installationszeit keinen Code aus, und Benutzer müssen das Paket selbst lokalisieren, um die darin enthaltene python.exe zu starten.

Einbettbares Paket

Das einbettbare Paket für CPython wird als Teil unseres normalen Release-Prozesses erstellt und veröffentlicht. Es wird zusammen mit dem traditionellen Installer auf python.org veröffentlicht. Der Inhalt ist identisch, jedoch ist das Layout so geändert, dass alle Binärdateien auf der obersten Ebene gespeichert werden und die Standardbibliothek in eine ZIP-Datei gepackt ist. Eine ._pth-Datei ist enthalten, um sys.path zu überschreiben, sodass nur die Dateien verwendet werden, die Teil der Distribution sind, und Umgebungsvariablen oder Registrierungseinträge ignoriert werden.

Dieses Paket enthält pip nicht, da die Absicht ist, es in eine umfassendere Anwendung einzubetten. Andere Bibliotheken sollten zur Build-Zeit installiert werden, da die Laufzeit nach der Verteilung ein internes Implementierungsdetail der App sein soll, zu der sie gehört.

Neben der beabsichtigten Verwendung versuchen einige Benutzer auch, dieses Paket als Entwicklungskit anstelle eines Laufzeitpakets zu verwenden. Dies liegt vermutlich daran, dass diese Benutzer "schwergewichtige" Installer vermeiden möchten und glauben, dass dieses Paket für eine "portablere" Installation gedacht ist (entpacken und ausführen), wahrscheinlich weil es die einzige ZIP-Datei-Option auf den Download-Seiten von python.org ist (was die Bedeutung von Klarheit und die Begrenzung von Optionen auf diesen Seiten unterstreicht). Es wird gehofft, dass ein zukünftiges Installer-Design diese Verwirrung vermeiden oder einschränken wird.

Alternative Distributionen

Obwohl außerhalb unseres Zuständigkeitsbereichs als Kernteam, verwenden alternative Distributionen von Python für Windows oft ein projekt-, workflow- oder umgebungsorientiertes Modell für die Installation der Laufzeitumgebung. Damit meinen wir, dass das Tool zuerst installiert wird und dann zur Erstellung eines Arbeitsbereichs verwendet wird, der eine Laufzeitumgebung sowie andere Abhängigkeiten enthält. Beispiele für diese Tools sind conda und uv.

Zwei Beobachtungen sind bei diesen Tools erwähnenswert. Erstens werden sie oft für geringe Auswirkungen gelobt, da sie in der Regel keine zusätzlichen Einstiegspunkte oder Dateien für die Laufzeitumgebung installieren, was die Installation schnell und auch auf ein einzelnes Projekt isoliert macht. Zweitens schätzen ihre Benutzer oft die einfache Auswahl einer bestimmten Version einer Laufzeitumgebung oder alternativ die Tatsache, dass sie keine auswählen müssen, da bestehende Spezifikationen (oder Einschränkungen) sie auswählen können.

Diese Tools erfüllen tendenziell viele der oben genannten zweiten Erwartungssätze und kombinieren oft mehrere Aufgaben in einem einzigen Befehl, um den kognitiven Aufwand beim Erlernen der Verwendung und Kombination mehrerer Befehle zu reduzieren.

Es ist auch erwähnenswert, dass das Kernteam diese alternativen Distributionen nicht als Konkurrenten zu einer Upstream-Distribution betrachtet. Sie sind ein fundamentaler Bestandteil dessen, wie das Open-Source-Ökosystem funktionieren soll. Unsere eigenen Distributionen sind eine Annehmlichkeit für diejenigen, die sich für ihre Nutzung entscheiden, da nicht alle Szenarien gut von einem Workflow-Tool oder sogar einem vorgefertigten Paket bedient werden.

Herausforderungen

Es gibt zahlreiche Herausforderungen bei den aktuellen Installer-Sets, die sich größtenteils in zwei Kategorien einteilen lassen: unpassende oder unerfüllbare Benutzererwartungen und allgemeine Unzuverlässigkeit.

Der traditionelle Installer weist die höchste Unzuverlässigkeit auf. Die Windows Installer-Technologie ist sehr alt und effektiv nicht mehr in der Entwicklung. Während ihre grundlegende Funktionalität in Ordnung ist, kann die Interferenz aus vielen Quellen kommen, wie z. B. Virenscannern, anderen Installern, Systemkonfigurationen, Administratorrichtlinien und sogar anderen Dateien im selben Verzeichnis wie der Installer. Darüber hinaus sind die meisten ihrer fortschrittlichen und nützlichen Funktionen wie Update-Patches, inkrementelle Updates und automatischer Rollback für Python-Benutzer unwichtig.

Die meisten Benutzererwartungen werden *durch* den traditionellen Installer *definiert*, und somit erfüllt er sie per Definition. Eine Hauptlücke besteht darin, dass er keine "unverwaltete" Installation erstellen kann – das heißt, das Äquivalent, Dateien nur auf das System des Benutzers zu kopieren, ohne Registrierung. Wenn Sie es einmal installiert haben und versuchen, es erneut zu installieren, können Sie nur die bestehende Installation verwalten (oder aktualisieren). Dies kann dazu führen, dass Installationen bei Updates verschoben werden, was für Benutzer zu Problemen führt.

Zusätzlich kann die PATH-Umgebungsvariable nicht intelligent modifiziert werden – im besten Fall können wir den Installationspfad voranstellen oder anhängen. Dies führt normalerweise dazu, dass die zuletzt installierte Python-Version die höchste Priorität hat. Wenn der Benutzer beispielsweise Python 3.14 installiert hat und dann 3.13 installiert (oder aktualisiert), wechselt der Befehl python von der späteren zur früheren Version.

Der py.exe-Launcher, der in PEP 397 definiert und implizit durch PEP 514 aktualisiert wird, ist ein Versuch, dieses spezielle Problem zu vermeiden. Er verwendet seine eigene Logik, um installierte Versionen zu finden, ohne sich auf PATH zu verlassen. Die PEP 514-Logik erlaubt jedoch keine spezielle Behandlung von Vorab- oder experimentellen Builds, und so bevorzugt py.exe oft diese Builds standardmäßig gegenüber der vom Benutzer erwarteten nicht-experimentellen Version.

Das Windows Store-Paket ist sehr zuverlässig, mit Ausnahme der globalen Verknüpfungen. Anstatt PATH zu modifizieren, um das eigene Verzeichnis hinzuzufügen, werden diese Verknüpfungen in einem einzigen, vom Betriebssystem verwalteten Verzeichnis erstellt, das alle von jeder App definierten Verknüpfungen enthält. Benutzer können ihren PATH modifizieren, um dieses Verzeichnis auszuschließen oder zu de-priorisieren, was zu unzuverlässigem oder inkonsistentem Verhalten führt, und historisch wurde dies auch durch Installer verursacht. Zum Beispiel wird die Installation von Python aus dem Store gefolgt von der Installation von Python aus dem traditionellen Installer mit aktivierter PATH-Modifikation fast immer das Python des Store-Pakets mit der späteren Installation überschatten.

Benutzererwartungen, die vom Store-Paket nicht erfüllt werden, tendieren dazu, leistungs- und technikbezogen zu sein. Aufgrund des Overheads beim Starten einer App startet Python langsamer. Da Apps so konzipiert sind, dass sie voneinander isoliert sind, ist es schwieriger, versteckte Verzeichnisse (wie AppData oder TEMP) zu verwenden, um zwischen verschiedenen Python-Versionen zu kommunizieren, da jede Version ihren eigenen Bereich hat. Apps unterliegen strengeren Sicherheitsanforderungen, die Legacy-Anwendungen normalerweise deaktiviert haben, wie z. B. der Schutz vor DLL-Hijacking, was dazu führt, dass einige Bibliotheken fehlschlagen. Die Verknüpfungen python3 und python werden über Systemeinstellungen verwaltet, und die Benutzeroberfläche ist nicht sehr gut (und wird laut Microsoft nicht verbessert). Ohne die Verwaltung dieser Einstellungen ist es relativ einfach, eine unerwünschte Version zu starten, obwohl die Ziele im Allgemeinen nur manuell vom Benutzer geändert werden können und nicht einfach durch die Installation einer anderen App.

Sowohl das NuGet-Paket als auch die einbettbare Distribution sind so einfach und zuverlässig zu installieren wie das Extrahieren eines Archivs, obwohl es erwähnenswert ist, dass dies für viele Python-Benutzer keine gängige Aufgabe ist. Sie bieten keinerlei Installationsmanagement und können nicht zuverlässig aktualisiert werden, außer durch Löschen und erneutes Extrahieren. Benutzererwartungen, die nicht erfüllt werden, sind fast immer auf die Wahl des falschen Installers durch die Benutzer zurückzuführen. Beide Pakete sind für spezielle Fälle gedacht, und obwohl sie als solche dokumentiert sind, führt die Anziehungskraft einer reinen ZIP-Datei zu Fehlern bei einigen Benutzern.

Ersetzen anderer Installer

Unsere Absicht ist es, sofort die Veröffentlichung einzelner Versionen im Windows Store einzustellen und den traditionellen Installer bis Python 3.16 als veraltet zu erklären und auslaufen zu lassen. Die einbettbare Distribution wird bestehen bleiben, aber ihre Auflistung auf den Download-Seiten von python.org wird auslaufen und sie wird nur über PyManager verfügbar sein. An den NuGet-Paketen werden keine Änderungen vorgenommen.

PyManager wird als App-Paket verfügbar sein, das manuell von python.org heruntergeladen werden kann, und das Double-Click-Installationserlebnis ist generell reibungslos. Dies bietet ein Äquivalent zum aktuellen Ansatz des Downloads von unserer Website. Es wird eine aktuelle (nicht spezifizierte) Version von CPython bündeln, sodass der Download auf einen Rechner ohne Internetverbindung übertragen werden kann und nach der Installation immer noch eine Python-Laufzeitumgebung bereitstellt.

Einige automatisierte Bereitstellungsszenarien funktionieren nicht mit dem neueren MSIX-Format, daher wird auf python.org auch ein einfaches MSI bereitgestellt. Dieses hat keine Optionen oder Benutzeroberfläche und erfordert Administratorrechte, die für diese Art von Szenarien typischerweise verfügbar sind. Zusätzlich wird das MSI von Benutzern auf nicht-standardmäßigen Systemen wie Wine benötigt, die das MSIX-Format nicht unterstützen. Obwohl nicht offiziell unterstützt, ermöglicht das MSI diesen Plattformen, weiterhin Upstream-Distributionen von CPython zu verwenden. Das MSI würde für die meisten anderen Benutzer abgeraten und das MSIX gilt als Standard.

Es ist erwähnenswert, dass es keine Möglichkeit gibt, die MSI-Installation vollständig mit der MSIX kompatibel zu machen, und Benutzer mit beiden werden wahrscheinlich Verwirrung oder Probleme haben. Es wird davon ausgegangen, dass nur Benutzer ohne Store-App-Unterstützung das MSI verwenden werden.

Unsere Release-Prozesse werden beginnen, reine ZIP-Pakete auf python.org zu veröffentlichen. Diese werden auf den FTP-Seiten verfügbar sein, werden aber nicht direkt auf den regulären Download-Seiten aufgeführt.

Drittanbieter-Tools, die derzeit ihre eigenen Builds von CPython vertreiben, sind willkommen, unsere zu verwenden, werden aber voraussichtlich der erste Ansprechpartner für ihre Benutzer sein, die Unterstützung benötigen.

Projektbesitz und -entwicklung

PyManager wird in einem eigenen Repository neben dem CPython-Repository und unter denselben Bedingungen entwickelt und gepflegt. Die CPython CLA gilt, und alle (und nur) Kernentwickler haben Commit-Rechte.

PyManager-Releases sind unabhängig von CPython-Releases. Es besteht keine Notwendigkeit, dass Versionen übereinstimmen oder Releases simultan erfolgen. Sofern nicht anders vereinbart, ist der PyManager-Release-Manager derjenige, der der Build-Manager für Windows ist.

Exec-Unterbefehl

py [-V:<TAG>] [interpreter opts] [script.py|-m module|-c code] [script args]
py [-3.*] [interpreter opts] [script.py|-m module|-c code] [script args]
python ...
python3 ...
pymanager exec -V:tag ...
pymanager exec -3.* ...

Dieser Unterbefehl wird verwendet, um eine Laufzeit auszuwählen und zu starten. Er ist die Standardaktion für den Befehl py und die einzige Aktion, die von den Befehlen python und python3 unterstützt wird. Die Standardoptionen sind in jedem Fall subtil unterschiedlich, um die Übereinstimmung mit der bestehenden Nutzung dieser Befehle zu gewährleisten.

Dieser Unterbefehl ist sowohl unter py als auch unter pymanager verfügbar. Da py ihn jedoch standardmäßig anbietet, würden wir nicht erwarten, dass Benutzer ihn dort verwenden. Die Absicht ist, dass die Befehle py, python und python3 die Standardwege zum Starten einer Laufzeit sind, und pymanager exec für fortgeschrittene Szenarien.

Der Befehl -V:tag wird verwendet, um zur Laufzeit eine bestimmte Laufzeitumgebung von der Befehlszeile aus anzufordern. Der Tag ist ein Firma\\Tag-Paar oder nur ein Tag, wenn kein Schrägstrich enthalten ist, und wird wie in PEP 514 definiert verwendet. Die Option -3.* wird als -V:PythonCore\\3.* interpretiert. Diese Option ist nur für die Varianten py und py exec verfügbar.

Wenn auf der Befehlszeile kein Tag angegeben ist und eine Skriptdatei angegeben wird, wird das Skript auf einen Shebang-Zeiger untersucht. Wenn ein übereinstimmendes Muster gefunden wird, wird entweder der zu verwendende Tag für die Suche bereitgestellt, oder die gesamte weitere Verarbeitung wird überschrieben und die angegebene ausführbare Datei wird ohne weitere Bemühungen gestartet. Dies dient der (unglücklichen) Legacy-Unterstützung für beliebige Windows-spezifische Pfade, die in einem eigentlich für Portabilität gedachten Feature erlaubt waren. Im Allgemeinen sind Shebangs, die einfache Muster wie /usr/bin/python3.13 enthalten, beabsichtigt, während solche, die /usr/bin/env python verwenden, wahrscheinlich keinen Nutzen bringen, da die Umgebung dazu neigt, weniger zuverlässig zu sein als unsere Suche.

Wenn zu diesem Zeitpunkt noch kein Tag angefordert wurde, wird die Umgebungsvariable VIRTUAL_ENV abgefragt, um festzustellen, ob eine Umgebung aktiviert wurde. Wenn dies der Fall ist, wird diese zur Anforderung.

Wenn zu diesem Zeitpunkt ein Tag angefordert wurde, verifiziert der Befehl python3, dass er mit PythonCore\\3.* übereinstimmt, und bricht mit einem Fehler ab, wenn dies nicht der Fall ist. Dies ermöglicht, dass der Befehl python3 in einer aktiven Umgebung konsistent mit anderen Plattformen verwendet werden kann, aber nicht, wenn die Umgebung den Befehl nicht enthalten hätte. Dies gilt für die meisten bestehenden Python-Versionen unter Windows. (Die Alternative zu diesem Verhalten wäre, python3 immer fehlschlagen zu lassen, wenn eine Umgebung aktiv ist, da alles andere inkonsistent für den Benutzer wäre.)

Wenn kein Tag angefordert wird, wird die Standardeinstellung konsultiert. Für python3 ist dies PythonCore\\3, aber für alle anderen Befehle wird sie aus der Konfiguration gelesen (was eine Umgebungsvariable beinhalten kann). Wenn sie immer noch leer ist, wird jeder Tag erlaubt.

Die am besten installierte Laufzeitumgebung, die dem Tag entspricht, wird dann ausgewählt und mit der restlichen Befehlszeile gestartet.

Wenn keine passende Laufzeitumgebung gefunden wird, werden die Befehle py exec und pymanager exec automatisch eine installieren und starten (sofern die Benutzereinstellungen dies zulassen). Die Befehle py, python und python3 werden einen Fehler melden und beenden. Wenn jedoch überhaupt keine Laufzeitumgebungen verfügbar sind, einschließlich keiner von anderen Installern erkannten, wird die erste Laufzeitumgebung automatisch installiert. Dies bietet eine nützliche Erststart-Erfahrung, bei der ein neuer Benutzer, der PyManager gerade installiert hat, direkt die neueste (oder angeforderte) Version von CPython startet. Nach diesem ersten Mal werden wieder Fehler gemeldet, wenn eine angeforderte Laufzeitumgebung nicht gefunden wird.

Install-Unterbefehl

py install [-s|--source <URL>] [-f|--force] [-u|--upgrade] tag [...]
py install [-s|--source <URL>] [-t|--target <DIR>] tag
py install [-s|--source <URL>] [-d|--download <DIR>] tag [...]
py install --refresh

Dieser Unterbefehl installiert eine oder mehrere Laufzeitumgebungen auf der aktuellen Maschine. Die Tags sind Firma\\Tag-Paare (oder nur Tag, wenn kein Schrägstrich enthalten ist) und werden verwendet, um die Indexdatei zu durchsuchen. Firmennamen stimmen fallunabhängig als Präfixe überein, wobei eine vollständige Übereinstimmung einem Präfix vorgezogen wird, und Tags verwenden fallunabhängige, nummernfreundliche Übereinstimmungen, wobei punktierte Zahlen als Versionen behandelt werden. Tags müssen mit einem der aufgeführten „install for“-Tags übereinstimmen, und Einträge listen mehrere solcher Tags auf, um abgekürzte Anfragen zu handhaben. Der spezielle Tag default löst zur konfigurierten Standardeinstellung des Benutzers auf (typischerweise 3; siehe Konfiguration weiter unten für Details zur Konfiguration von Einstellungen).

Tags können auch als Einschränkung angegeben werden, mit >, >=, <, <= oder != gefolgt vom Firma\\Tag- oder Tag-Wert. Bei der Übereinstimmung mit einer Einschränkung werden nur die primären Tag-Metadaten für Vergleiche verwendet. Da die Vergleiche versionsbewusst sind, wählen Einschränkungen wie >3.10 mindestens 3.11 aus, während >3.10.0 3.10.1 auswählen kann.

Das Verhalten von Einschränkungen gegenüber beliebigen Tags ist unter Umständen wahrscheinlich unintuitiv. Es wird erwartet, dass Einschränkungen hauptsächlich mit Upstream-Releases verwendet werden, die typischerweise versionsförmige Tags verwenden, und hauptsächlich für Fälle, in denen andere Metadaten wie Requires-Python gehandhabt werden. Von Benutzern wird erwartet, dass sie kürzere Tags zur Bequemlichkeit verwenden, anstatt Bereiche.

Die Standard-Indexdatei wird auf python.org gehostet und enthält Installationsinformationen, einschließlich Paket-URLs und Hashes für alle installierbaren Versionen. Ein alternativer Index kann vom Benutzer über eine Konfigurationsdatei oder die Befehlszeilenoption --source oder von seinem Administrator über eine Konfigurationsdatei angegeben werden. Der angeforderte Tag wird mit der Indexdatei abgeglichen, und wenn eine exakte Übereinstimmung gefunden wird, wird das Paket ausgewählt. Bei keiner exakten Übereinstimmung wird ein Präfix-Match verwendet. In beiden Fällen werden Zahlen im Tag logisch behandelt - d. h. 3.1 ist ein Präfix von 3.1.2, aber nicht von 3.10. Siehe Index-Schema unten für Informationen darüber, wie Installations-Tags genau im Index verzeichnet sind.

Wenn ein Tag bereits durch eine bestehende Installation erfüllt ist, wird nichts installiert. Der Benutzer muss eine Option --upgrade oder --force übergeben, um die bestehende Installation zu ersetzen; die erste ersetzt sie nur durch eine neuere Version, während die letztere sie auch mit derselben Version entfernt und ersetzt.

Der Aufruf des Befehls ohne Angabe von Tags installiert nichts, zeigt aber den Hilfetext und einen Fehler an (wie bei jeder ungültigen Option). Das Übergeben von --upgrade ohne Tags versucht jedoch, alle Installationen zu aktualisieren.

Das Übergeben von --refresh generiert alle Metadaten und Verknüpfungen für alle Installationen neu. Dies wird absichtlich auf alle Installationen gleichzeitig angewendet, da die Priorisierung von Verknüpfungen davon abhängt, dass alle Installationen konsistent sind (zum Beispiel sollte die neueste 3.x-Version die python3.exe-Verknüpfung erhalten, was kompliziert wird, wenn Benutzer sich entscheiden, nur eine ältere Installation zu aktualisieren).

Wenn eine Option --target <VERZ> mit nur einem einzigen Tag übergeben wird, wird diese Laufzeit in das angegebene Verzeichnis extrahiert, ohne als Installation registriert zu werden (oder Aliase oder Verknüpfungen zu generieren). Dies ist für Einbettungsfälle oder das Herunterladen von Dateien für inkompatible Plattformen gedacht. Das Übergeben mehrerer Tags mit --target ist ein Fehler.

Wenn die Option --download <VERZ> übergeben wird, werden Laufzeitpakete heruntergeladen, aber nicht installiert. Sie werden in dem angegebenen Verzeichnis als ihre Quellpakete gespeichert und eine index.json wird erstellt, die auf diese Dateien verweist. Dieser Index kann später verwendet werden, um Offline-Installationen mit python install --source <index.json> [tag ...] durchzuführen.

Uninstall-Unterbefehl

py uninstall [-y|--yes] [--purge] [tag ...]

Dieser Unterbefehl deinstalliert eine oder mehrere Laufzeitumgebungen auf der aktuellen Maschine. Tags sind genau wie beim Installationsbefehl, einschließlich Präfixübereinstimmung, aber es werden nur bestehende Installationen inspiziert. Sofern nicht die Option --yes übergeben wird, wird der Benutzer vor der Deinstallation jeder Laufzeitumgebung gefragt.

Wenn die Option --purge ohne Tags übergeben wird, werden (nach Bestätigung) alle Laufzeitumgebungen zusammen mit Verknüpfungen und allen zwischengespeicherten Dateien entfernt. Das Übergeben von Tags mit --purge führt zu einem Fehler.

Die Deinstallation von PyManager deinstalliert keine installierten Laufzeitumgebungen. Aus technischen Gründen wäre dies nicht zuverlässig möglich (wir können keine beliebigen Code bei der Deinstallation ausführen), und so stellen wir bewusst sicher, dass alles, was installiert wurde, weiterhin funktioniert. Die Neuinstallation von PyManager ermöglicht die Wiederaufnahme der Verwaltung dieser Installationen. Das Ausführen von py uninstall --purge vor der Deinstallation von PyManager führt eine vollständige Deinstallation durch.

List-Unterbefehl

py list [-f|--format <FMT>] [-1|--one] [--only-managed] [tag ...]
py list [-f|--format <FMT>] [-1|--one] [--online] [--source <URL>] [tag ...]
py [--list|--list-paths|-0|-0p]

Dieser Unterbefehl listet alle oder ausgewählte Installationen auf, die den angegebenen Tags oder Bereichen entsprechen. Wenn keine Tags angegeben werden, werden alle Installationen aufgelistet. Nicht von PyManager verwaltete Laufzeitumgebungen (einschließlich einer aktiven virtuellen Umgebung) können separat aufgeführt werden.

Das Standardformat ist benutzerfreundlich. Andere Formate umfassen maschinenlesbare und einzelne String-Formate (z. B. --format=prefix gibt einfach sys.prefix auf einer eigenen Zeile aus). Die genaue Liste der Formate ist der Implementierung überlassen.

Wenn --one übergeben wird, wird nur das beste Ergebnis aufgelistet. Dies dient zur Unterstützung von Shell-Skripten, die die Standard- (oder eine geeignete) Laufzeitumgebung lokalisieren möchten, ohne sie zu starten. (Beachten Sie, dass „beste“ lose definiert ist, aber immer die bevorzugte Standardumgebung des Benutzers ist, wenn sie in den Ergebnissen enthalten ist.)

Die Option --only-managed lässt Laufzeitumgebungen weg, die zwar entdeckt, aber nicht von PyManager verwaltet wurden, zum Beispiel solche, die mit einer regulären PEP 514-Suche gefunden wurden.

Das Übergeben von --source (oder --online, um implizit die Standardquelle zu übergeben) sucht in einem Online-Index statt nach aktuell installierten Laufzeitumgebungen. Die Option befindet sich hier und nicht im Unterbefehl install, da die Filter- und Formatierungsoptionen bereits bei list verfügbar sind.

Die Legacy-Argumente --list, --list-paths, -0 und -0p vom py.exe-Launcher werden ebenfalls bereitgestellt. Sie unterstützen jedoch nicht die hier aufgeführten neuen Optionen und sind darauf beschränkt, die Ausgabe des bestehenden Launchers zu reproduzieren. Nicht verwaltete Installationen sind in dieser Auflistung nicht unterscheidbar.

Help-Unterbefehl

py help <COMMAND>

Dieser Unterbefehl zeigt den Hilfetext für jeden angegebenen Befehl an oder, wenn keiner angegeben ist, die Liste der Befehle. Das Angeben eines Befehls ist äquivalent zu py <BEFEHL> --help. Das Anzeigen der Liste der Unterbefehle ist die Standardaktion für den Befehl pymanager.

Der Befehl wird hauptsächlich hinzugefügt, um Benutzern eine einfache Möglichkeit zu bieten, wie sie weitere Informationen finden können: Sie können angewiesen werden, py help auszuführen. Dies erspart die Notwendigkeit, die Ausgabe von python -? zu überschreiben oder zu erweitern, die ansonsten an die ausgewählte Laufzeitumgebung weitergeleitet wird und bereits mindestens einen Bildschirm Text ausgibt.

Nach einer automatischen Installation (z. B. beim Ausführen von python, wenn nichts installiert ist) wird eine Meldung angezeigt, die den Benutzern mitteilt, dass sie py help ausführen können, um weitere Informationen zur Verwaltung ihrer Installationen zu erhalten.

Umgebungsvariablen

Umgebungsvariablen können bei der Installation einer Store-App nicht automatisch aktualisiert werden, daher werden keine automatischen Aktualisierungen vorgenommen. Die Kernbefehle sollten auf einem korrekt funktionierenden Rechner bereits verfügbar sein.

Ein Verzeichnis innerhalb des PyManager-Datenverzeichnisses des Benutzers ist für generierte Aliase vorgesehen. Wenn gewünscht, kann der Benutzer dieses Verzeichnis selbst zu seinem PATH hinzufügen. Der Inhalt dieses Verzeichnisses wird von PyManager verwaltet und enthält ausführbare Dateien zum direkten Starten installierter Laufzeitumgebungen (z. B. python3.exe und python3.13.exe für eine Installation von Python 3.13). Wann immer Aliase zu diesem Verzeichnis hinzugefügt werden, wird PATH überprüft und, wenn er fehlt, wird dem Benutzer eine Meldung mit dem hinzuzufügenden Pfad angezeigt.

Skripte, die von Paketen installiert wurden, die in einer Laufzeitumgebung installiert sind, befinden sich in einem weiteren Verzeichnis. Aufgrund des aktuellen Designs glauben wir nicht, dass es sicher ist, sie alle in einem einzigen Verzeichnis oder einem Verzeichnis, das von mehreren Laufzeitumgebungen gemeinsam genutzt wird, zu installieren. Eine zukünftige Entwicklung könnte jedoch einen Befehl für PyManager beinhalten, um eigene Einstiegspunkte basierend auf Metadaten in installierten Paketen zu generieren.

Startmenü-Verknüpfungen

Eine Startmenü-Verknüpfung wird hinzugefügt, um die PyManager-Dokumentation im Standard-Webbrowser des Benutzers zu starten. Es werden keine Anwendungen zum Startmenü hinzugefügt.

Beim Installieren von Python-Laufzeitumgebungen kann die Installationsdefinition Startmenü-Verknüpfungen für die Installation angeben.

Dateizuordnungen

Beim Installieren von PyManager werden Standard-Dateizuordnungen erstellt, die Skripte und Paket-Apps mit dem globalen python.exe-Alias von PyManager starten. Dies bietet ein sinnvolles Verhalten für Benutzer, die auf Skripte oder .pyz-Dateien doppelklicken.

Fenster-Executables

Für jeden der zuvor beschriebenen globalen Aliase existiert auch eine *w.exe. Diese starten ohne Erstellung oder Anhängen eines Konsolenfensters, was typischerweise bedeutet, dass sie nur Benutzeroberflächen anzeigen, die vom Skript erstellt wurden. IDLE startet zum Beispiel immer mit pythonw.exe, da dies eine unnötige native Konsole vermeidet.

Diese Befehle verhalten sich ansonsten identisch zu ihren Konsolen-Gegenstücken.

Konfiguration

PyManager wird über eine Hierarchie von JSON-basierten Konfigurationsdateien konfiguriert. Befehlszeilenoptionen überschreiben immer Konfigurationsdateien. Konfigurationsdateien an benutzereditierbaren Speicherorten können durch eine Konfigurations- oder Befehlszeilenoption deaktiviert werden.

In aufsteigender Reihenfolge der Priorität werden dieseLocated

• innerhalb des App-Pakets
• angegeben durch administrator-exklusive Konfiguration (siehe unten)
• in der Einstellung base_config (Standard: keine)
• in der Einstellung user_config (Standard: %AppData%\\Python\\PyManager.json)
• in der Einstellung additional_config (Standard: %PYTHON_MANAGER_CONFIG%)
• angegeben mit der Befehlszeilenoption -c

Das spezifische Verhalten jeder Konfigurationsoption ist der Implementierung überlassen. Es werden jedoch eine Reihe von beabsichtigten Optionen in anderen Abschnitten diskutiert.

App-Paket-Konfiguration wird bereitgestellt, um PyManager in andere Anwendungen oder Pakete einzubetten. Eine alternative Distribution kann beispielsweise PyManager enthalten wollen, aber diese von ihrem eigenen Index Installationen finden lassen. Die App-Paket-Konfiguration erlaubt die Wiederverwendung unseres Builds und die Überschreibung der Standardeinstellungen.

Die Einstellungen user_config und additional_config sind in früheren Konfigurationsdateien voreingestellt und erlauben daher die Überschreibung durch administrator-exklusive Konfiguration oder eine alternative Root-Konfiguration. Wenn eine Konfigurationsdatei die Einstellung überschreibt, die zum Laden der Datei geführt hat, wird sie ignoriert. Die Einstellung base_config ist ähnlich, beginnt aber leer und ist für eine einfache Überschreibung durch Administrator-Konfigurationen gedacht.

Administrator-exklusive Konfiguration wird bereitgestellt, um Administratoren die Verwaltung von Systemen unter ihrer Kontrolle mit bestehenden Tools wie Gruppenrichtlinien oder Registrierungsaktualisierungen zu ermöglichen. Von Design her können diese Steuerungen nicht überschrieben werden, so dass es Administratoren möglich ist, Richtlinien bereitzustellen, die die Verwendung von PyManager verhindern oder einschränken. Diese Steuerungen sind unerlässlich, um PyManager sicher in bestimmten Umgebungen einsetzen zu können, und ohne sie wäre er einfach nicht erlaubt und diese Benutzer hätten keinen Zugriff auf Python.

Die Absicht ist, dass die Haupt-Administrator-Konfiguration ein Pfad zu einer neuen Konfigurationsdatei base_config ist, die ein Administrator an jedem kontrollierten Ort bereitstellen kann. Dies ermöglicht es einem Netzwerkadministrator, die Quelle der Standard-Python-Laufzeitumgebungen seiner Benutzer zu steuern, ohne sie zwangsweise einzuschränken, oder die anderen Quellen für Konfigurationsdateien zu überschreiben (abgesehen von der Befehlszeilenoption).

Indexschema

Die Indexdatei ist entweder online oder lokal verfügbar und stellt PyManager alle Informationen zur Verfügung, die benötigt werden, um jede Python-Laufzeitumgebung zu finden, auszuwählen, zu installieren und zu verwalten.

Der Index ist als JSON gespeichert. Der Hauptschlüssel auf oberster Ebene ist versions, der eine Liste von Objekten enthält. Jedes Versions-Objekt hat eine eigene Schema-Version, und es gibt keine allgemeine Datei-Schema-Version. Zukünftige Änderungen können zusätzliche Schlüssel auf oberster Ebene hinzufügen, um Funktionalität bereitzustellen, die nicht sicher in eine bestehende integriert werden kann.

Versions-Objekte können zwischen der Indexdatei und einer __install__.json im Stammverzeichnis jedes Paketarchivs aufgeteilt werden. Die Einträge in der gebündelten Datei füllen Lücken aus der Indexdatei auf. Dies ist dazu gedacht, den typischerweise großen Schlüssel shortcuts aus der Indexdatei zu entfernen, kann aber auch auf alias, executable und executable_args erweitert werden. Das Auslassen anderer Schlüssel aus dem Index kann zu Problemen bei der Installation des Pakets führen. Die Gewährleistung des korrekten Verhaltens liegt bei der Implementierung – dies ist kein Interoperabilitätspunkt, und so beabsichtigen wir nicht, die Details hier anzugeben (über die normalen Kompatibilitätsanforderungen hinaus).

Ein zweiter Schlüssel auf oberster Ebene, next, enthält eine optionale URL zu einem anderen Index. Dies kann verwendet werden, wenn PyManager kein geeignetes Paket in den enthaltenen Versionen finden kann. Die Absicht ist, ältere Indizes archivieren und nur bei Bedarf darauf zugreifen zu können, wodurch die Größe des anfänglichen Downloads reduziert wird, ohne Benutzer von älteren Versionen abzuschneiden. Bei der Suche nach einer geeigneten Installation werden spätere Indizes nicht durchsucht, wenn ein tragfähiger Kandidat gefunden wird (mit anderen Worten, der erste konsultierte Index sollte die neuesten Versionen enthalten).

Das initiale Schema ist unten gezeigt

SCHEMA = {
    "versions": [
        {
            # Should be 1.
            "schema": int,

            # Unique ID used for install detection/side-by-side.
            # Must be valid as a filename.
            "id": str,

            # Name to display in the UI
            "display-name": str,

            # Version used to sort packages. Also determines prerelease status.
            # Should follow Python's format, but is only compared among releases
            # with the same Company.
            "sort-version": Version,

            # Specifies platforms to consider this package for.
            # Initially, 'win32' is the only supported value. Others may be
            # defined in the future. This condition is evaluated silently, and
            # is not intended to replace platform requests in "install-for".
            "platform": [str],

            # Company field, used for filtering and displayed as the publisher.
            "company": str,

            # Default tag, mainly for UI purposes.
            # It should also be specified in 'install-for' and 'run-for'.
            "tag": str,

            # List of tags to install this package for. This does not have to be
            # unique across all installs; the first match will be selected.
            # For example, the 3.10.5 package may list '3', '3.10' and
            # '3.10.5' so that any of those may be specified to install it.
            # Matches are number aware, so that 3.1 is not a prefix of 3.10.
            "install-for": [str],

            # List of tags to run this package for. Does not have to be unique
            # across all installs; the first match will be selected. The target
            # is the executable path relative to the root of the archive.
            # Explicit args (optional) are inserted before user args.
            "run-for": [{"tag": str, "target": str, "args": [str], "windowed": int}, ...],

            # List of global CLI aliases to create for this package. Does not
            # have to be unique across all installs; the first match will be
            # created.
            "alias": [{"name": str, "target": str, "windowed": int}, ...],

            # List of shortcuts to create for this package. Additional keys on
            # each instance are allowed based on the value of 'kind'.
            # Initially, 'kind' supports the following values:
            # * 'pep514' - other keys define registry values to set
            # * 'start' - generate shortcuts in the user's Start Menu
            # * 'uninstall' - generate an Add/Remove Programs entry
            "shortcuts": [{"kind": str, ...}, ...]

            # Default executable path, relative to the root of the archive.
            # Usually the values from 'run-for' will be used instead, and this
            # is mainly for display purposes.
            "executable": str,
            # Default executable args
            "executable_args": [str],

            # URL to download the package archive from
            "url": str,

            # Optional set of hashes to validate the download. Hashes are stored
            # as hex digests. Any hash supported by hashlib without OpenSSL is
            # permitted.
            "hash": {
                "<hash_name>": str,
            }
        }
    ],

    # URL (or relative path) to the next index file
    "next": str,
}

Shebang-Verarbeitung

Für begrenzte Kompatibilität mit Skripten, die für Sh-ähnliche Shells konzipiert sind, prüft PyManager Skripte auf eine Shebang-Zeile. Eine Shebang-Zeile, die einen Python-Befehl angibt, wird (sofern nicht auf der Befehlszeile überschrieben) verwendet, um eine geeignete Laufzeitumgebung für das Skript auszuwählen.

Im Gegensatz zur derzeitigen Unterstützung im py.exe-Launcher schlagen wir vor, diese Funktionalität auf Python-Befehle zu beschränken, bei denen der Befehl mit einem globalen Alias übereinstimmt, der für eine Installation aufgeführt ist, und alles, was nicht übereinstimmt, als beliebiger ausführbarer Pfad behandelt wird. In der Praxis wird dies voraussichtlich zu denselben (oder besseren) Ergebnissen für nicht-kontingente Fälle führen, kann aber zu subtilen Änderungen führen, wo Benutzer von nicht spezifizierten Randfallverhalten des bestehenden Launchers abhängen.

Die spezifischen Muster, die erkannt werden sollen, sind der Implementierung überlassen, sollten aber weitgehend mit dem bestehenden Launcher kompatibel sein.

„Ändern“ des Befehls python.exe

Es könnte argumentiert werden, dass der von PyManager bereitgestellte globale Alias python.exe „kein echtes Python“ ist und daher einen anderen Namen verwenden sollte. Obwohl dies streng genommen richtig ist, gibt es drei Gründe, warum wir argumentieren, dass er verwendet werden sollte.

Erstens installieren Tausende von Benutzern *täglich* über die Store-Seite, nachdem sie dorthin geführt wurden, indem sie python auf dem Terminal eines sauberen Rechners eingegeben haben. Aufgrund der Implementierung dieser Weiterleitung, wenn die von ihnen installierte App keinen python-Befehl bereitstellt, bleibt die Weiterleitung bestehen. Um sicherzustellen, dass die Benutzer nicht immer wieder zum Store zurückkehren, müssen wir diesen Befehl bereitstellen. (Das Gleiche gilt für python3.)

Zweitens ist die Alternative zum „nicht echten“ Alias nicht der „echte“. Es ist nichts. Wir können den globalen statischen Alias nicht durch einen ersetzen, der die Präferenzen oder Installationen des Benutzers widerspiegelt, so dass die Alternative wäre, nichts bereitzustellen und python in allen Fällen zu einem Fehler zu machen. Das ist schlechter und unserer Meinung nach schädlich für den Ruf von Python.

Drittens ist zwar die zugrundeliegende Implementierung des Alias python komplexer als der Standard Programs/python.c, aber die Erfahrung mit ihm ist identisch. Der Alias wird nur in Abwesenheit anderer ausdrücklicher Präferenzen gestartet (d. h. nichts anderes im PATH), er respektiert indirekte Präferenzen (z. B. über Konfiguration oder Shebangs) und er startet die am besten geeignete Version von Python, die auf dem Rechner des Benutzers verfügbar ist. Dies kommt dem gewünschten Verhalten des globalen Befehls python näher als jede Alternative.

Es wurde angemerkt, dass Gentoo auch einen intelligenten Befehl python verteilt, um seinen Benutzern einen besseren Dienst zu erweisen als ein einfaches Symlink.

Ersetzen von py.exe

Der py.exe-Launcher existiert, um einen Teil der Funktionalität bereitzustellen, die von PyManager repliziert werden wird – insbesondere die Fähigkeit, eine bereits installierte Laufzeitumgebung zu starten. Trotz seiner langen Geschichte scheint der Launcher für die meisten Benutzer nicht die bevorzugte Methode geworden zu sein, wobei viele globale Änderungen an der Umgebungsvariable PATH bevorzugen. Der Befehl selbst ist jedoch in Gebrauch geraten und sollte so lange wie möglich beibehalten werden. Dies wird auf zwei Arten erreicht.

Erstens installieren wir unseren eigenen py.exe-Alias mit PyManager, der dieselbe Funktionalität bietet, zusammen mit PyManager-spezifischer Funktionalität. Dieser soll im Laufe der Zeit die Standard-/bevorzugte Installation von py.exe werden.

Zweitens generieren wir (auf Anfrage) PEP 514-Metadaten für jede Installation, die es einem Legacy- py.exe ermöglicht, mit von PyManager verwalteten Installationen normal weiterzuarbeiten.

Aufgrund der Art und Weise, wie der bestehende py.exe-Launcher sich selbst konfiguriert und wie das MSIX-Paket für PyManager eingeschränkt ist, ist es PyManager nicht möglich, dass der py-Alias den Launcher überschreibt. Infolgedessen werden Benutzer, die den Launcher installieren, immer py auf den Launcher auflösen. Letztendlich ist die einzige Möglichkeit, dies zugunsten von PyManager zu lösen, die Deinstallation des Launchers, was über die standardmäßige Systemsteuerung „Installierte Apps“ erfolgen kann.

Wir schlagen vor, den bestehenden Launcher, der weiterhin mit dem traditionellen Installer veröffentlicht wird, zu aktualisieren, um versuchte Verwendungen der neuen Unterbefehle zu erkennen und dem Benutzer eine nützliche Meldung anstelle des aktuellen Fehlers anzuzeigen. Diese Warnungen können auch den unwahrscheinlichen Fall erkennen, dass ein Benutzer absichtlich dateiendungslose Dateien unter diesen Namen startet, und dieses Verhalten beibehalten, was eine praktikable Alternative für Benutzer ermöglicht, die ihr Setup nicht ändern können.

Interaktion mit venv

Eine aktivierte virtuelle Umgebung, wie sie vom Modul venv der Standardbibliothek implementiert wird, modifiziert die Umgebungsvariable PATH des Benutzers, um sicherzustellen, dass der venv-Launcher Vorrang vor anderen ausführbaren Dateien hat. Daher kann PyManager, wenn ein venv aktiviert wurde, nur durch seine Aliase außer python gestartet werden. Wenn eine aktive virtuelle Umgebung erkannt wird, wird sie als Standard-Laufzeitumgebung des Benutzers behandelt (außer bei der Deinstallation), was sicherstellt, dass auch andere Befehle wie erwartet funktionieren.

Das bedeutet, dass funktionierende virtuelle Umgebungen so funktionieren, wie sie es heute tun, ohne zusätzliche Unterstützung von PyManager.

Skriptgesteuerte Downloads

Benutzer, die Skripte zum Generieren des Download-Dateinamens unseres alten Installers geschrieben haben, werden feststellen, dass ihre Skripte fehlerhaft sind. Diese URLs waren nie garantiert stabil oder vorhersagbar, und so können wir nichts anderes tun, als uns zu entschuldigen und vorzuschlagen, dass Benutzer unsere eigenen Werkzeuge für Downloads verwenden.

Die Übergangsfrist für den traditionellen Installer gibt diesen Benutzern Zeit, sich über die bevorstehende Änderung zu informieren. Wo möglich, werden wir dem traditionellen Installer Deprecation-Warnungen hinzufügen.

Skriptgesteuerte Installationen

Benutzer, die Skripte zum Ausführen unseres Installers mit bestimmten Optionen geschrieben haben, müssen ihre Skripte ändern. Die meisten Optionen wurden zunächst entfernt, und die verbleibenden haben eine neue Schreibweise. Da es nicht möglich ist, einen Zustand zu erreichen, in dem Optionen für den alten Installer an den neuen übergeben werden, ohne manuelle Eingriffe (d. h. jemand muss den Befehl ändern, der bereits vorhanden ist), wird dies als akzeptable Änderung betrachtet.

Die Übergangsfrist für den traditionellen Installer gibt diesen Benutzern Zeit, sich über die bevorstehende Änderung zu informieren. Wo möglich, werden wir dem traditionellen Installer Deprecation-Warnungen hinzufügen.

Alter Laufzeit-Installer

Benutzer mit bereits installierten Laufzeitumgebungen werden feststellen, dass diese von PyManager und seinen Aliassen ausgewählt werden, vorausgesetzt, die Registrierung ist nicht beschädigt.

Die Prioritätsreihenfolge unter den installierten Laufzeitumgebungen wurde geändert, um nur Vorabversionen einzuschließen, wenn sie ausdrücklich angefordert werden (z. B. entspricht -V:3 3.14.0 und nicht 3.15.0a1, aber -V:3.15 entspricht 3.15.0a1), und um Suffixe bei Tags korrekt zu sortieren (z. B. ist 3.14t nun von *geringerer* Priorität als 3.14).

Während es möglich ist, Warnungen auszugeben, wenn dies einen Benutzer beeinträchtigen könnte, würden solche Warnungen als sehr lautstark angesehen (z. B. eine Meldung jedes Mal, wenn Sie python starten, weil Sie eine Vorabversion installiert haben, die nicht ausgewählt wurde) und erfordern eine unnötige Komplexität der Auswahl-Logik. Diese Änderung wird nur dokumentiert.

Alter py.exe-Launcher installiert

Benutzer, die keinen alten py.exe-Launcher manuell deinstallieren, werden feststellen, dass sowohl ihre vorhandenen als auch ihre neuen Python-Installationen gefunden werden, obwohl bei übereinstimmenden Versionen die vorhandene Installation Vorrang vor der neuen Installation hat (während das neue py die neue Installation auswählen würde).

Sie werden auch feststellen, dass Befehle wie py list nicht funktionieren. Die Lösung hier ist die Verwendung der Windows-Einstellungen zur Deinstallation des Launchers.

Es gibt keine Möglichkeit zu erkennen, dass ein Benutzer versehentlich ein altes py installiert gelassen hat, oder es für ihn zu entfernen. Diese Änderung wird nur dokumentiert.

Falsch konfigurierter venv aktiviert

Benutzer, die eine beschädigte oder falsch konfigurierte virtuelle Umgebung aktivieren, bei der entweder python.exe fehlt oder sie nicht im PATH steht, erhalten möglicherweise eine andere Fehlermeldung als zuvor.

Der globale python-Alias von PyManager wird gefunden und ausgeführt, wodurch ein systemweiter „nicht gefunden“-Fehler unterdrückt wird. Da er die tatsächliche Laufzeitumgebung der Umgebung nicht findet, wird er fehlschlagen, obwohl der Code und die Meldung unterschiedlich sein können.

Da dieses Szenario ein bereits beschädigtes System erfordert, wird diese Änderung nur dokumentiert.

Verfügbarkeit alter Versionen

Python-Versionen vor der ersten Veröffentlichung von PyManager können in den python.org-Index aufgenommen werden, entweder basierend auf neu verpackten Archiven oder unter Verwendung der fast gleichwertigen Pakete von NuGet (letztere enthalten kein Tcl/Tk, was sie für einige Benutzer erheblich inkompatibel macht, aber das ist wahrscheinlich für besonders alte Versionen in Ordnung).

Mit der Akzeptanz dieses PEPs ist geplant, Pakete für alle Versionen von Python 3.10.0 und höher (einschließlich Patch-Releases, aber ausgenommen Vorabversionen) zu erstellen, so dass alle nicht-EOL-Releases vollständig mit PyManager installiert werden können. Versionen ab Python 3.5.0 (ausgenommen Vorabversionen) werden direkt auf die Pakete bei NuGet verweisen, wodurch sie in reduzierter Form leicht verfügbar sind. Keiner der Ansätze erfordert eine Neukompilierung der bestehenden Releases, noch sind Änderungen an den Quellen dieser Releases erforderlich.

Administratoren-Installationen

Die Installation einer Kopie von Python für alle Benutzer ist nicht mehr möglich, da PyManager nur in das eigene Verzeichnis des Benutzers installiert. Es wurde kein Szenario vorgelegt, das zeigt, dass per-Machine-Installationen im Einklang mit unserer Absicht für die Upstream-Distribution stehen, daher werden wir keine Option dafür anbieten. Drittanbieter, die diese Funktionalität wünschen, sind aufgefordert, ihre eigenen Distributionen anzubieten.

PyManager kann nur für alle Benutzer installiert werden, obwohl eine MSIX-Installation keine Administratorrechte erfordert und von einem Administrator umfassend konfiguriert werden kann, einschließlich der Einschränkung der tatsächlichen Laufzeitumgebungen, die Benutzer installieren dürfen. Darüber hinaus unterstützt PyManager die lokale Extraktion für Bündelungen, so dass einbettende Apps leicht ihr eigenes Layout generieren können, das bei Bedarf für alle Benutzer installiert werden kann.

Da dieses Szenario Administratorinterventionen mit oder ohne Änderungen erfordert, wird dies nur dokumentiert.

Build-Zeit-Installationen

Benutzer, die die einbettbare Distribution verwenden, müssen möglicherweise zu einer neuen Methode wechseln, um die URL zu den Paketen zu finden, obwohl die Empfehlung wäre, PyManager zum Auffinden und Installieren zu verwenden. Es werden keine Unterschiede aufgrund der Änderung des Installers erwartet, und das Paket der einbettbaren Distribution wäre identisch mit heute.

Es werden keine Änderungen an den NuGet-Paketen vorgeschlagen.

Einzelarchitektur-Installer

Der aktuelle Vorschlag stellt nur eine 64-Bit-Intel-Version von PyManager zur Verfügung. Dies verhindert, dass Benutzer auf reinen 32-Bit-Betriebssystemen oder CPUs PyManager installieren können. Da dies heute nur einen winzigen Bruchteil der Maschinen ausmacht und einen noch kleineren Anteil der Entwicklermaschinen (die Zielgruppe für PyManager), sind wir nicht besorgt, Benutzer auszuschließen.

Windows ARM64-Maschinen unterstützen die Ausführung von Binärdateien, die für Intel 64-Bit erstellt wurden, durch effiziente Emulation. 32-Bit-Versionen von CPython bleiben verfügbar, da sie eine wichtige Rolle bei der Integration mit 32-Bit-Ausführbaren Dateien spielen, die keine Ersetzung durch 64-Bit-Binärdateien zulassen. Da PyManager als eigenständige ausführbare Datei ausgeführt wird, ist dies für den Manager keine notwendige Funktion.

Testsuite und Debug-Symbole

Der vorhandene Installer ermöglicht optional die Installation der Testsuite der Python-Standardbibliothek sowie die optionale Installation von Debug-Symbolen. Keines davon ist für die meisten Benutzer notwendig, aber für einige bequem. Vorläufige Tests zeigen, dass das Weglassen der Testsuite und der Debug-Symbole etwa 60 % der Größe des komprimierten Pakets einspart (von 46 MB auf 18 MB).

Die "Standard"-CPython-Pakete, die von PyManager installiert werden, enthalten daher weder die Testsuite noch die Debug-Symbole. Es wird jedoch einen zweiten Satz von Paketen geben, die diese Extras enthalten, gruppiert unter PythonTest (im Gegensatz zum Standard, PythonCore). Zum Beispiel würde py install 3.13 den Standard installieren, während py install PythonTest\\3.13 eine zweite Laufzeitumgebung mit den zusätzlichen Dateien installieren würde (die entweder mit py -V:PythonTest\\3.13 oder einfach py -V:3.13 gestartet werden kann, wenn keine entsprechende PythonCore-Version installiert ist).

Debug-Binärdateien werden nicht mehr verteilt, und alle anderen optionalen Funktionen sind standardmäßig enthalten.

Globaler Pip-Befehl

Im Gegensatz zur aktuellen Installation aus dem Windows Store ist kein globaler pip-Befehl enthalten (der traditionelle Installer enthält ebenfalls keinen globalen pip-Befehl, es sei denn, die Optionen zum Ändern von PATH und zur Installation von pip sind ausgewählt; die erste davon ist standardmäßig deaktiviert). Dies wirkt sich auf die globale Installation von Paketen aus, was bereits nicht empfohlen wird, hat aber keine Auswirkungen auf aktivierte virtuelle Umgebungen.

Die bestehende Empfehlung bleibt bestehen, nämlich python -m pip oder py -V:<TAG> -m pip auszuführen, um pip zu starten.

Grundlegende Verwendung

Ein zentrales Ziel dieses Vorschlags ist es, dass "tippe 'python' in dein Terminal" für die grundlegendsten Fälle eine ausreichende Anweisung ist. Dank des von Microsoft hinzugefügten Redirectors wird die Befolgung dieser Anweisung zumindest zu etwas Nützlichem führen, und mit PyManager können wir sicherstellen, dass "etwas Nützliches" bedeutet, dass der Benutzer die neueste Version ausführt.

Um zu erklären, was tatsächlich passiert, schlagen wir als einführenden Text folgendes vor

Python installs on Windows are managed using an installer tool. After it has
been installed, you can run ``python`` to launch the interpreter, and it will
choose the best version already installed, available online, or referenced by
the script you are launching (if any). If you have a preference for a
particular version, you can specify it with ``py -V:<version>`` followed
by the rest of your command.

To install a version of Python without running any command, use ``py install
<version>``. You can see all of your installs with ``py list`` and remove them
with ``py uninstall <version>``. Run ``py help`` to see all the options that
are available.

Because each version of Python will be shared by all your projects, we
recommend using virtual environments. This will usually be created for a
particular Python version by running ``py -V:<version> -m venv .venv``, and
activated with ``.venv\Scripts\Activate``. Now, rather than the install
manager, ``python`` or ``py`` will always launch your virtual environment, and
any packages you install are only available while this environment is active.
To get access to the manager again, you can ``deactivate`` the environment, or
use ``py <command>``.

Viele Python-Projekte enthalten in ihren README-Dateien Informationen darüber, wie ihre Projekte gestartet werden können. Historisch gesehen waren solche Informationen aufgrund der Bandbreite der dem Benutzer zur Verfügung stehenden Optionen kompliziert. Wir schlagen vor, dass nach der Veröffentlichung des Installationsmanagers solche Anleitungen ungefähr so formuliert werden könnten

To install and use our application, first install Python following the
guidance for your operating system at https://docs.pythonlang.de/using/. Then,
create a virtual environment and use 'pip' to install.

``python3 -m venv .venv``
``source .venv/bin/activate`` or ``.venv\Scripts\Activate`` (on Windows)
``python -m pip install OurAwesomePackage``
...

Wenn die Anweisungen keine Informationen über virtuelle Umgebungen enthalten, dann kann der Befehl python oder python3 angezeigt werden, und unter Windows funktionieren beide wie beabsichtigt für Benutzer mit dem Installationsmanager.

Anweisungen, die sich derzeit auf py für Windows beziehen, können dies weiterhin tun, da der Installationsmanager einen praktisch gleichwertigen Befehl bereitstellt. Projekte, die Windows-spezifische Anweisungen bereitstellen möchten, z. B. durch die Verwendung der Optionen -V: oder --install zur Installation der richtigen Version, sollten auch die Dokumentation als Anleitung zur Sicherstellung der Installation des Installationsmanagers verlinken.

Deinstallation

Die vollständige Deinstallation ist ein wichtiges Thema, das behandelt werden muss, bevor ein Benutzer die Deinstallation des Installationsmanagers in Erwägung zieht. Da nicht alle Teile von Installationen automatisch aufgeräumt werden können, wenn der Manager deinstalliert wird, entscheiden wir uns dafür, die meisten davon nicht zu entfernen. Während also die Standardbefehle python und py verschwinden, bleiben alle installierten Laufzeitumgebungen erhalten und nutzbar.

Wir schlagen eine Erklärung wie diese vor

Before you uninstall the Python install manager, you'll want to uninstall any
runtimes that you added. This can be done easily with the "purge" option:

``py uninstall --purge``

This will remove all installs and any shortcuts that would otherwise be left
behind. If you already removed the manager, you can reinstall it and run the
above uninstall command again to clean up. Individual runtimes can be
uninstalled by specifying the tag instead of ``--purge``. Tags can be found
by looking at ``python list``.

Konfiguration

Konfigurationsdateien sind ein übliches Merkmal, das dokumentiert wird, aber normalen Benutzern nicht beigebracht werden muss. Ebenso werden fortgeschrittene Bereitstellungsoptionen, wie sie von Systemadministratoren oder Organisationen genutzt werden könnten, die möchten, dass ihre Benutzer einen bevorzugten Index verwenden, am besten im Referenzmaterial behandelt.

Benutzerdefinierter Index

Wir schlagen vor, dass Indizes nur dann eingeführt werden müssen, wenn Benutzer angewiesen werden, eine spezialisierte Laufzeitumgebung oder Distribution zu installieren. Administratoren, die einen Index bereitstellen möchten, werden voraussichtlich aktiv die relevanten Informationen in der Dokumentation suchen.

Um zu erklären, wie und wann ein alternativer Index verwendet wird, schlagen wir Text wie diesen vor

Our distribution can be installed on Windows using the Python Install Manager
(include link) by referencing our index:

``py install --source <your index URL here> latest``

This index contains all our versions. Use ``py list --source <URL>`` to
see everything that is available.

PyManager auf allen Plattformen verfügbar machen

Obwohl wir dieser Idee nicht grundsätzlich abgeneigt sind, setzt sie voraus, dass viele weitere Komponenten aufeinander abgestimmt sind, bevor sie umgesetzt werden kann.

Erstens enthält die Referenzimplementierung bisher viele Windows-spezifische Kenntnisse. Entsprechende Kenntnisse für andere Plattformen müssten gesammelt und implementiert werden, ebenso wie zusätzliche Verhaltensweisen, die für Nicht-Windows-Plattformen spezifisch sind.

Zweitens benötigen wir eine Quelle für vorgefertigte, verlagerbare Binärdateien, die auf das System extrahiert werden können. Obwohl solche Quellen existieren, können wir sie aufgrund unserer Position in der Lieferkette nicht rechtfertigen (sie sollten uns nutzen). Für Windows erfüllen unsere eigenen Binärdateien diese Kriterien bereits, sodass wir sie ohne Modifikationen neu verpacken können.

Drittens basiert die aktuelle Implementierung auf einer gebündelten Python-Laufzeitumgebung, die aus offensichtlichen Gründen von jeglicher Benutzereingriffe isoliert werden muss. Dies würde auch die oben genannten verlagerbaren Binärdateien erfordern, die wir derzeit nur für Windows haben.

Aufgrund der zusätzlichen Schritte, die erforderlich sind, um dies auf anderen Plattformen funktionsfähig zu machen, und der Tatsache, dass es keine Notwendigkeit gibt, bestehende Installer für diese Plattformen zu ersetzen, betrachten wir diese Idee für dieses PEP als nicht relevant. Sie könnte in Zukunft weiterverfolgt werden (und die Mitwirkenden, die dazu am wahrscheinlichsten neigen, haben signalisiert, dass sie sich damit befassen und eine konsistente Schnittstelle nutzen könnten).

Einen Laufzeit-Interpreter vorinstalliert mit dem Manager einschließen

Der Vorschlag ist, eine vollständige Python-Laufzeitumgebung mit PyManager aufzunehmen, damit dessen python.exe-Alias direkt darauf verweisen kann, anstatt dynamisch die beste verfügbare Version aufzulösen.

Für Stabilität und Updates ist es sehr wichtig, dass Laufzeitumgebungen vollständig unabhängig vom Manager sind. Das Aktualisieren des Managers sollte möglich sein, ohne bestehende Laufzeitumgebungen zu beeinträchtigen, und ebenso sollte keine Anforderung bestehen, den Manager zu aktualisieren, um eine neuere Laufzeitumgebung zu erhalten.

Hypothetisch gesehen, wenn wir Python 3.14.0 mit dem Manager aufnehmen würden, sodass es nicht installiert werden müsste, wäre die spätere Ersetzung durch 3.15.0 eine Änderung, die Kompatibilitätsprobleme verursacht. Da wir nur eine einzige Installation für den Manager haben, würde dies dazu führen, dass die neuesten Installationen die älteste Laufzeitumgebung erhalten.

Dies würde auch den Status des python-Alias von PyManager als nicht spezifizierte Version ignorieren – wenn der Benutzer diesen Alias aufruft, liegt das daran, dass ihm die Version egal war, die er bekommt, um sie zu spezifizieren. In dieser Situation sollten wir die beste verfügbare auswählen und ihm die Optionen geben, sie nach Bedarf zu stabilisieren (sei es durch ein Shebang oder eine aktive Umgebung).

Einen Laufzeit-Interpreter STATTDESSEN des Managers einschließen

Dies ist die aktuelle Situation, die wir ändern wollen. Wenn Sie bis hierher gelesen haben und immer noch dieses Argument vorbringen, gehen Sie bitte zurück und beginnen Sie von vorn.

Ein integriertes Modul anstelle von Unterbefehlen verwenden

Zwei Alternativen zur Verwendung von Befehlen wie py list oder py install, die vorgeschlagen wurden, sind die Verwendung dedizierter Module, die wie py -m list und py -m install aufgerufen werden, oder ein einziges dediziertes Modul, das wie py -m manage list aufgerufen wird. Diese Idee wird mit der Begründung abgelehnt, dass sie versucht, bestehende Semantiken für ein Szenario wiederzuverwenden, das mit diesen Semantiken nicht zuverlässig implementiert werden kann, und daher einen Sonderfall erfordern würde, der schwieriger zu erklären, zu verstehen und zu warten ist.

Der Hauptgrund für die Ablehnung dieser Idee ist die Wechselwirkung zweier ansonsten wünschenswerter Semantiken: Erstens sollte der Standard-py-Befehl die neueste verfügbare Laufzeitumgebung starten, als ob sie direkt gestartet worden wäre; und zweitens sollte das Verhalten von -m unter bestimmten Umständen nicht als Sonderfall behandelt werden. Wenn der erste Teil fallen gelassen würde, würden wir den Befehl frei ändern, um wie erwartet zu funktionieren – niemand würde Kompatibilitätsbedenken äußern, wenn wir uns darauf einigen würden, die Kompatibilität vollständig zu brechen. Wenn jedoch die zweite Einschränkung fallen gelassen würde, müssten die Benutzer die Verwirrung in Kauf nehmen. (Wir schlagen nicht vor, beide fallen zu lassen – dies ist schließlich eine abgelehnte Idee –, aber es hilft, die Optionen zu veranschaulichen.)

Erstens, da einer der Unterbefehle dazu gedacht ist, Ihre erste Laufzeitumgebung zu installieren, können wir python -m [manage] install nicht so behandeln, als ob er über die Standardlaufzeitumgebung ausgeführt würde – es gibt keine! Er erfordert zwangsläufig eine Sonderbehandlung, um den Befehl zu lesen und durch ein anderes Programm auszuführen.

Darüber hinaus erlaubt Python anderen Optionen, dem -m vorauszugehen oder sich damit zu vermischen, was von diesem Sonderfall unterstützt werden müsste.

Schließlich beinhaltet die Semantik der -m-Option die Suche im anfänglichen sys.path nach übereinstimmenden Modulnamen. Dies ist eine erheblich breitere Suche als ein nackter Name. py -m install würde gerne install.py, install.pyc, install.pyd, install\\__init__.py und mehr ausführen, nachdem eine Reihe von Verzeichnissen durchsucht wurden, die durch Inspektion des Dateisystems, der Umgebung, der Registrierung sowie aller transitiv enthaltenen Pfade gefunden wurden. Im Vergleich zu py install, das **nur** nach einer Datei namens install im aktuellen Arbeitsverzeichnis suchen würde, ist das -m-Verhalten weitaus wahrscheinlicher, dass es bereits von realen Szenarien genutzt wird. (Zum Beispiel haben Django-Projekte typischerweise ein manage.py-Skript, was bedeutet, dass py -m manage immer falsch funktionieren würde.)

Die Änderung von py -m install, sodass es sich **nicht** wie -m verhält, sondern stattdessen einen internen Befehl ausführt, ist weitaus wahrscheinlicher, Benutzer zu brechen, als py install zu ändern. Daher wird diese Idee abgelehnt.

Eine neue Befehlszeilenoption anstelle von Unterbefehlen verwenden

Eine sinnvolle Alternative zu Unterbefehlen ist die Angabe ihrer Namen mit führender Interpunktion, wie eine Option statt eines Unterbefehls. Zum Beispiel könnte dies aussehen wie py /install ... anstelle von py install oder py --list. Da einige dieser Befehle derzeit für einen normalen CPython-Interpreter Fehler sind, könnten sie ohne Bedenken hinsichtlich der Abwärtskompatibilität hinzugefügt werden.

Bezeichnenderweise ist das typische Windows-Format eines führenden Schrägstrichs jedoch kein Fehler in CPython. Windows-Benutzer können daher bestehendes Wissen nicht direkt übertragen und müssen eine neue Art der Optionsspezifikation lernen. Da wir ein Windows-spezifisches Tool vorschlagen, ist dies ein schlechter Anfang. Außerdem erkennen Benutzer, die mit Unix-ähnlichen Kommandozeilen vertraut sind, die missbräuchliche Verwendung von Optionen als Befehle.

Wir möchten eine saubere Schnittstelle schaffen, und ein Design, das offensichtliche Schönheitsfehler oder Lernherausforderungen enthält, steht diesem Ziel entgegen. Moderne Tools verwenden universell Unterbefehle für diese Zwecke, und daher wird die Idee, etwas anderes zu verwenden, abgelehnt.

Verbesserung des bestehenden traditionellen Installers

Anstatt einen neuen Installationsmechanismus zu schaffen, könnten wir in die Wartung des aktuellen Installers investieren. Zu diesem Zeitpunkt basiert unser aktueller Installer jedoch vollständig auf veralteter Technologie. Windows entwickelt den Windows Installer-Dienst nicht mehr weiter, und Wix verbessert die Version ihres Toolsets, das wir verwenden, nicht mehr. Die Migration zu einem neueren Wix Toolset ist ein erheblicher Arbeitsaufwand und bindet uns letztendlich immer noch an alte Technologien.

Wie bereits erwähnt, wird die vorteilhafteste Funktionalität, die vom Windows Installer bereitgestellt wird, nicht für CPython verwendet und hat im Allgemeinen mehr Probleme verursacht, als sie jemals gelöst hat (z. B. versehentliche Downgrades aufgrund automatisch gesammelter Dateiversionsinformationen).

Die Implementierung des Burn-Bundles, das unsere primäre Quelle für Installer-Logik ist, ist in C++ geschrieben und in ein Framework integriert, mit dem nur wenige Kernentwickler vertraut sind. Dies macht die Wartung schwierig und ist keine gute langfristige Position. Die Migration gewünschter Funktionen wie registrierungsfreier Installationen in das Burn-Bundle ist nicht möglich (ohne die End-to-End-Neuerstellung zu schreiben und sie nachträglich zu integrieren).

Unserer Meinung nach ist die Wartung des aktuellen traditionellen Installers mindestens genauso aufwändig wie die Implementierung eines neuen Installers und würde für das Kernteam oder unsere Benutzer keine nennenswerten Vorteile bringen. Daher wird diese Idee abgelehnt.

Das Store-Paket vollständig löschen

Das Entfernen der Store-Pakete würde die Anzahl der Optionen reduzieren, mit denen Benutzer bei der Auswahl einer Python-Laufzeitumgebung konfrontiert sind. Nach allen Maßstäben außer Zuverlässigkeit und Sicherheit ist der traditionelle Installer als Ersatz vollständig ausreichend. Die Bemühungen, Teile des Ökosystems auf sicherere Einstellungen umzustellen (wie z. B. nicht auf DLL-Hijacking zu setzen), sind größtenteils erfolgt, aber einige Pakete verbleiben, die immer noch nur mit weniger sicheren Konfigurationen funktionieren, und die Rückkehr aller Benutzer zu diesen Konfigurationen würde sicherstellen, dass Benutzer dieser Pakete nicht mit den Problemen konfrontiert werden, mit denen sie heute konfrontiert sind.

Die Mehrheit der Benutzer der Store-Pakete scheint jedoch keine Beschwerden zu haben. Anekdotisch sind sie oft vollständig mit der Store-Installation zufrieden und schätzen besonders die Einfachheit und Zuverlässigkeit der Installation. (Und persönlich nutzt dieser Autor seit Python 3.8 ausschließlich Store-Pakete ohne blockierende Probleme.)

Die meisten Probleme wurden durch falsch konfigurierte PATH-Variablen und den von Microsoft installierten Standard-python.exe-Redirector verursacht. Mit anderen Worten, völlig unabhängig von unserem eigenen Paket (obwohl manchmal mit unlösbaren Problemen in unserem anderen Installer verbunden). Im Interesse der hohen Anzahl erfolgreicher Installationen über diesen Weg halten wir die Belastung der Diagnose und Unterstützung betroffener Benutzer für lohnenswert und betrachten die Idee, das Store-Paket einfach zu entfernen, als abgelehnt.

Das bedeutet jedoch, dass wir, wenn PyManager im Store veröffentlicht wird, alle vorhandenen Laufzeitumgebungen im Store delisten würden, um sicherzustellen, dass Benutzer den Manager finden. Dies betrifft nur Neuinstallationen, und jeder, der zuvor eine bestimmte Version installiert hat (auch auf einem anderen Rechner, wenn er angemeldet war), kann diese Versionen weiterhin nutzen und installieren.

Auf WinGet oder Äquivalente zurückgreifen

WinGet, Chocolatey und andere ähnliche Tools sind keine Installer im von uns benötigten Sinne. Sie verwenden ihr eigenes Metadaten-Repository, um Installer herunterzuladen, zu validieren und auszuführen. Ohne unseren eigenen Installer haben sie nichts auszuführen und können daher nicht verwendet werden.

Es ist möglich, dass ihre Metadaten die Installation von PyManager und die anschließende Ausführung zur Installation einer bestimmten Laufzeitumgebung nicht unterstützen. In diesem Fall müssen sie möglicherweise die direkte Verwendung unserer Binärpakete untersuchen.

Derzeit werden keine dieser Installationstools offiziell von CPython unterstützt, daher sind wir nicht verpflichtet, sie zum Laufen zu bringen.

Jede Version zu einem Windows Store-Paket machen

Es ist möglich, jede Version wie bisher im Windows Store zu veröffentlichen, sie aber ungelistet zu machen und sich auf einen Installer zu verlassen (potenziell PyManager, WinGet oder ein anderes Tool, das Store-Pakete installieren kann). Dies würde das Risiko vermeiden, den Benutzer zu überfordern, und gleichzeitig unsere eigenen Verantwortlichkeiten für die Paketverwaltung erheblich vereinfachen.

Dieser Ansatz würde eine erhebliche Belastung für jeden Mitwirkenden darstellen, der Zugriff auf die Store-Veröffentlichungsoberfläche hat, da die Aktualisierung von Paketen eine manuelle Aufgabe ist. Darüber hinaus würden alle Python-Laufzeitumgebungen mit den zuvor beschriebenen technischen Einschränkungen behaftet sein. Daher wird diese Idee abgelehnt.

Jede Version als MSIX-Paket anstelle eines ZIP-Files zu veröffentlichen, würde zwar die Store-Veröffentlichungsoberfläche vermeiden, aber dennoch technische Einschränkungen für Benutzer mit sich bringen. Auch dies wird abgelehnt.

Nur die reine ZIP-Datei veröffentlichen

Die Veröffentlichung des reinen ZIP-Files ist Teil des Plans, es wird jedoch nicht sichtbar aufgeführt (z. B. auf den Download-Seiten von python.org, obwohl es in der FTP-Ansicht sichtbar sein wird). Eine Alternative wäre, diese Pakete zu veröffentlichen und aufzulisten und von Benutzern zu erwarten, dass sie sie herunterladen, manuell extrahieren und konfigurieren.

Angesichts der von uns beobachteten Arbeitsabläufe glauben wir, dass die meisten Benutzer überhaupt keine Python-Installation konfigurieren möchten. Sie möchten nicht nur nicht den Installationsort wählen, sondern auch keine Version wählen oder gar nach einem Download-Anbieter oder Anleitungen suchen. Sie möchten jedoch in der Lage sein, eine Installation später zu finden, zu starten, zu aktualisieren oder zu entfernen oder alle bekannten Installationen aufzulisten.

Es ist auch erwähnenswert, dass es mehr ZIP-Dateien geben wird, als derzeit auf den Download-Seiten aufgeführt sind, und somit wird die Liste der Dateien länger. Die Auswahl des richtigen Downloads ist für Benutzer bereits eine Herausforderung (diejenigen, die den primären "Download"-Button umgehen und die Liste aller verfügbaren Versionen und dann Dateien anzeigen), und wir haben kein Interesse daran, es schwieriger zu machen.

Das Indexprotokoll und die Download-Liste werden für Tools, die sie verwenden möchten, oder für Benutzer, die bereit sind, JSON zu durchsuchen, um die URL zu finden, verfügbar sein. Die --target-Option im Install-Befehl bietet ebenfalls eine einfache Download- und Extraktionsoperation, die Benutzern die gleiche Erfahrung wie mit einer ZIP-Datei ermöglicht. Und die --download-Option kann Benutzern immer noch das ZIP-File im gepackten Zustand geben.

PyManager nur an einem Ort veröffentlichen

Ob Windows Store oder python.org, es wäre machbar, nur an einem Ort zu veröffentlichen.

Benutzer erwarten jedoch dringend, **etwas** von python.org herunterladen zu können. Wenn wir eine Option entfernen würden, würden wir unseren Benutzern unweigerlich schaden. Ohne ein MSIX auf python.org haben Benutzer keine Möglichkeit, das Paket auf eine andere Maschine zu übertragen oder die anfängliche Installation des Managers vollständig zu skripten.

Viele Benutzer verlassen sich auf die Windows Store-App zur Installation von Paketen, und der in Windows integrierte Redirector kann nur zu einer Store-Seite geöffnet werden. Daher entspricht das Entfernen der Store-App der Verweigerung von Hunderttausenden von Installationen pro Monat.

Die beiden Builds sind praktisch identisch. Der einzige Unterschied zwischen dem MSIX, das wir dem Store zur Verfügung stellen, und dem, das an python.org geht, ist die Paket-Signierung: Wir signieren das python.org-Paket selbst, während das Store-Paket als Teil des Veröffentlichungsprozesses signiert wird. Ansonsten fallen keine zusätzlichen Kosten für die Erstellung und Veröffentlichung beider Pakete an.

Inline-Skript-Metadaten

PEP 723 hat Inline-Skript-Metadaten eingeführt, einen strukturierten Kommentar, der dazu bestimmt ist, dass Drittanbieter-Tools ihn interpretieren und dann ein Python-Skript in der richtigen Umgebung starten. Ein Beispiel aus diesem PEP

# /// script
# requires-python = ">=3.11"
# dependencies = [
#   "requests<3",
#   "rich",
# ]
# ///

PyManager verfügt über keine integrierte Unterstützung für die Installation von Abhängigkeiten und schlägt auch nicht vor, welche hinzuzufügen. Infolgedessen könnten wir die Verarbeitung dieser Metadaten nicht vollständig implementieren, und da wir eine teilweise Verarbeitung als schlechter als nichts betrachten, entscheiden wir uns, keine zu implementieren.

Es ist für einen Benutzer möglich, die Einschränkung direkt als Option anzugeben, zum Beispiel py -V:>=3.11 my-script.py, um das Auswahlverhalten zu erhalten.

Wir könnten die Metadaten auch erkennen und eine Warnung ausgeben, wenn die ausgewählte Laufzeitumgebung ihren Anforderungen nicht entspricht, aber dies ist nicht Teil des ursprünglichen Vorschlags.