Ablehnungsbescheid

Dieser PEP wurde mangels signifikanten Interesses abgelehnt.

Zusammenfassung

Dieser PEP schlägt Strategien vor, die es erlauben, die Python-Standardbibliothek in Teilen zu aktualisieren, ohne die vollständige Distribution neu installieren zu müssen oder auf eine neue Patch-Level-Version warten zu müssen.

Problem

Python erlaubt standardmäßig nicht das Überschreiben von Modulen oder Paketen in der Standardbibliothek. Obwohl dies durch die Definition einer PYTHONPATH Umgebungsvariablen möglich ist (die in dieser Variablen definierten Pfade werden vor den Pfad der Python-Standardbibliothek gestellt), gibt es keine standardmäßige Methode, dies ohne Änderung der Konfiguration zu erreichen.

Da die Python-Standardbibliothek zunehmend Pakete enthält, die auch separat verfügbar sind, z.B. die distutils-, email- und PyXML-Pakete, die auch unabhängig von der Python-Distribution installiert werden können, ist es wünschenswert, eine Option zu haben, diese Pakete zu aktualisieren, ohne auf eine neue Patch-Level-Version des Python-Interpreters warten zu müssen, um die Änderungen mitzubringen.

Gelegentlich kann es auch wünschenswert sein, Module der Standardbibliothek zu aktualisieren, ohne den gesamten Python-Release-Zyklus durchlaufen zu müssen, z.B. um Hotfixes für Sicherheitsprobleme bereitzustellen.

Vorgeschlagene Lösungen

Dieser PEP schlägt zwei unterschiedliche, aber nicht notwendigerweise widersprüchliche Lösungen vor

1. Hinzufügen eines neuen Standard-Suchpfads zu sys.path: $stdlibpath/system-packages direkt vor dem $stdlibpath Eintrag. Dies ergänzt den bereits vorhandenen Eintrag für Site-Add-ons $stdlibpath/site-packages, der zur Laufzeit des Interpreters an sys.path angehängt wird.

   Um diesen neuen Standard-Speicherort zu nutzen, muss distutils die Unterstützung für die Installation bestimmter Pakete in $stdlibpath/system-packages statt im Standard-Speicherort für Drittanbieter-Pakete $stdlibpath/site-packages erweitern.

2. Anpassen von distutils, um für System-Upgrades direkt in $stdlibpath statt in $stdlibpath/site-packages zu installieren.

Die erste Lösung hat einige Vorteile gegenüber der zweiten

• Upgrades können leicht identifiziert werden (einfach in $stdlibpath/system-packages nachschauen)
• Upgrades können deinstalliert werden, ohne die restliche Interpreter-Installation zu beeinträchtigen
• Module können virtuell aus Paketen entfernt werden; dies liegt an der Art und Weise, wie Python Pakete importiert: Sobald es das Verzeichnis des Top-Level-Pakets gefunden hat, bleibt es in diesem Verzeichnis für alle nachfolgenden Paket-Submodul-Imports
• Der Ansatz hat insgesamt ein viel saubereres Design als der "hackige" Ansatz, auf einer bestehenden Installation aufzubauen

Die einzigen Vorteile des zweiten Ansatzes sind, dass der Python-Interpreter nicht geändert werden muss und er mit älteren Python-Versionen funktioniert.

Beide Lösungen erfordern Änderungen an distutils. Diese Änderungen können auch von Paketautoren implementiert werden, aber es wäre besser, eine standardmäßige Methode zu definieren, um das vorgeschlagene Verhalten zu aktivieren.

Umfang

Lösung 1: Python 2.6 und höher

Lösung 2: Alle von distutils unterstützten Python-Versionen

Danksagungen

Keine

Referenzen

Keine

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.