Zusammenfassung

Die Standard-Python-Distribution enthält ein Verzeichnis Lib/site-packages, das auf Unix-Plattformen zur Speicherung lokal installierter Module und Pakete verwendet wird. Das site.py-Modul, das mit Python verteilt wird, unterstützt das Auffinden anderer Module im site-packages-Verzeichnis.

Dieses PEP schlägt vor, dass das site-packages-Verzeichnis auf der Windows-Plattform in ähnlicher Weise verwendet werden sollte.

Motivation

Auf Windows-Plattformen enthält die Standardeinstellung für sys.path kein geeignetes Verzeichnis für Benutzer, um lokal entwickelte Module zu installieren. Der "erwartete" Speicherort scheint das Verzeichnis zu sein, das die Python-Executable selbst enthält. Dies ist auch der Ort, an dem distutils (und von distutils generierte Installer) Pakete installiert. Lokaler Code im selben Verzeichnis wie installierte Executables aufzunehmen, ist keine gute Praxis.

Natürlich können Benutzer sys.path manipulieren, entweder in einer lokal geänderten site.py-Datei, in einer geeigneten sitecustomize.py-Datei oder sogar über .pth-Dateien. Es sollte jedoch einen standardisierten Speicherort für solche Dateien geben, anstatt darauf zu vertrauen, dass jede einzelne Site ihre eigene Richtlinie festlegt.

Darüber hinaus wird mit der zunehmenden Verbreitung von distutils als Mittel zur Verteilung von Modulen der Bedarf an einem Standardinstallationsort für verteilte Module immer wichtiger. Es wäre besser, einen solchen Standard jetzt zu definieren, anstatt später, wenn es mehr distutils-basierte Pakete gibt, die neu kompiliert werden müssen.

Es ist erwähnenswert, dass vor Python 2.1 das site-packages-Verzeichnis nicht in sys.path für Macintosh-Plattformen enthalten war. Dies wurde in 2.1 geändert, und Macintosh enthält jetzt sys.path, sodass Windows die einzige große Plattform ohne ein site-spezifisches Modulverzeichnis ist.

Implementierung

Die Implementierung dieser Funktion ist recht trivial. Alles, was erforderlich wäre, ist eine Änderung an site.py, um den Abschnitt zur Einstellung von sitedirs zu ändern. Die Python 2.1-Version hat

if os.sep == '/':
    sitedirs = [makepath(prefix,
                        "lib",
                        "python" + sys.version[:3],
                        "site-packages"),
                makepath(prefix, "lib", "site-python")]
elif os.sep == ':':
    sitedirs = [makepath(prefix, "lib", "site-packages")]
else:
    sitedirs = [prefix]

Eine geeignete Änderung wäre, einfach die letzten 4 Zeilen zu ersetzen durch

else:
    sitedirs == [prefix, makepath(prefix, "lib", "site-packages")]

Auch an distutils müssten Änderungen vorgenommen werden, um diese Richtlinienänderung zu berücksichtigen. Ein Patch ist auf Sourceforge verfügbar, Patch-ID 445744, der diese Änderung implementiert. Beachten Sie, dass der Patch die Python-Version prüft und das neue Verhalten nur für Python-Versionen ab 2.2 aufwärts aufruft. Dies soll sicherstellen, dass distutils mit früheren Python-Versionen kompatibel bleibt.

Schließlich muss der ausführbare Code, der den Windows-Installer implementiert, der von dem bdist_wininst-Befehl verwendet wird, geändert werden, um den neuen Speicherort zu verwenden. Hierfür ist ein separater Patch verfügbar, der derzeit von Thomas Heller gepflegt wird.

Anmerkungen

• Diese Änderung schließt Pakete, die den aktuellen Speicherort verwenden, nicht aus – die Änderung fügt sys.path lediglich ein Verzeichnis hinzu, sie entfernt nichts.
• Sowohl der aktuelle Speicherort (sys.prefix) als auch das neue Verzeichnis (site-packages) sind in sitedirs enthalten, sodass .pth-Dateien an beiden Orten erkannt werden.
• Dieser Vorschlag fügt sitedirs ein einziges zusätzliches site-packages-Verzeichnis hinzu. Auf Unix-Plattformen werden zwei Verzeichnisse hinzugefügt, eines für versionsunabhängige Dateien (Python-Code) und eines für versionabhängigen Code (C-Erweiterungen). Dies ist auf Unix notwendig, da die sitedirs einen gemeinsamen (über Python-Versionen hinweg) Paket-Speicherort enthalten, standardmäßig unter /usr/local. Da auf Windows kein solcher gemeinsamer Speicherort verfügbar ist, gibt es auch keinen Bedarf für zwei getrennte Paketverzeichnisse.
• Wenn Benutzer DLLs an einem einzigen Ort unter Windows speichern möchten, anstatt sie im Paketverzeichnis zu lagern, ist das DLLs-Unterverzeichnis des Python-Installationsverzeichnisses bereits für diesen Zweck verfügbar. Das Hinzufügen eines zusätzlichen Verzeichnisses nur für DLLs sollte nicht notwendig sein.

Offene Fragen

• Kommentare von Unix-Benutzern deuten darauf hin, dass es mit dem aktuellen Setup auf der Unix-Plattform Probleme geben könnte. Anstatt sich mit plattformübergreifenden Problemen zu befassen, beschränkt sich dieses PEP speziell auf die Windows-Plattform und überlässt Änderungen für andere Plattformen anderen PEPs.
• Es könnte Probleme mit Anwendungen geben, die Python einbetten. Nach Kenntnis des Autors sollte es durch diese Änderung keine Probleme geben. Es gab keine Kommentare (unterstützend oder anderweitig) von Benutzern, die Python einbetten.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.