Python Distutils-SIG

Vorgeschlagene Benutzeroberfläche

Zusätzlich zur Identifizierung der gemeinsamen Aufgaben und Arbeitsteilung bei der Entwicklung, Verteilung und Installation von Python-Modulen ergab die Developer's Day Session "Extension Building Considered Painful" auch eine vorgeschlagene Benutzeroberfläche. Die Kernidee der Benutzeroberfläche ist, dass der Modulentwickler ein kleines Python-Skript bereitstellt, das zur Veranschaulichung `setup.py` genannt wird (obwohl gehofft wird, dass sich diese Konvention durchsetzt!). Dieses Skript hätte zwei Komponenten: Metadaten über die Modulverteilung (Name, Versionsnummer, Beschreibung usw.), geschrieben als eine Art Python-Code; und optionaler Code zur Inspektion des Zielsystems und zur Durchführung notwendiger Konfigurationsoperationen vor dem Build. Nur die Metadaten sind erforderlich, und es wird erwartet, dass die meisten Modulverteilungen (insbesondere solche, die rein in Python geschrieben sind) nur die Metadatenkomponente enthalten. Nachfolgend werden einige Ideen zur Darstellung der Metadaten vorgestellt.

Dieses Dokument beschreibt eine Schnittstelle, die auf dem basiert, worauf wir uns auf der Developer's Day Session geeinigt haben, jedoch mit vielen weiteren Details. (Einige dieser Details könnten als Implementierung statt als Schnittstelle interpretiert werden, aber es ist wichtig, sie irgendwo zu spezifizieren.)

Sobald das `setup.py`-Skript geschrieben ist, werden Entwickler, Packager und Installer es gleichermaßen verwenden, um alle ihre Aufgaben auszuführen, die automatisiert werden können (d. h. alles außer dem eigentlichen Schreiben der Module, Dokumentation und Testsuite). Dies geschieht durch Ausführung von `setup.py` mit einem obligatorischen "Kommando"-Argument, das der zu erledigenden Aufgabe entspricht. (Durch reinen Zufall werden viele dieser Kommandos den traditionellen `makefile`-Zielen ähneln.)

Zum Beispiel ist der Befehl zum Initiieren eines Builds `build`. Der Entwickler, Packager und Installer (zumindest ein Installer, der von einer Quellverteilung aus arbeitet) müssen alle die Module bauen, indem sie den folgenden Befehl verwenden

    ./setup.py build

    ./setup.py test

    ./setup.py dist

    ./setup.py bdist

    ./setup.py bdist -rpm

Mittlerweile fragen Sie sich wahrscheinlich, was *wirklich* hinter jedem dieser Befehle passiert. Man könnte argumentieren, dass dies ein Implementierungsdetail ist, das nicht in einen Schnittstellen-Vorschlag gehört, aber ich denke, dass die meisten Entwickler, viele Packager und einige neugierige Benutzer dazu neigen werden, "unter die Haube" zu schauen und zu sehen, was wirklich vor sich geht, während sie Modulverteilungen bauen und installieren. (Und die Unglücklichen müssen den Prozess verstehen, wenn etwas schief geht!) Daher ist hier eine Liste von Befehlen, die von `setup.py` (durch Zusammenarbeit mit den **distutils**-Modulen) unterstützt werden, und die Aktionen, die jedem Befehl entsprechen

make_blib

Erstellt, falls noch nicht vorhanden, einen simulierten Installationsbaum, `blib/`, im aktuellen Verzeichnis. `blib/` würde Verzeichnisse für reinen Python-Code (nicht architekturabhängig oder gemeinsam genutzt) und kompilierten Code (architekturabhängig) enthalten, die den Verzeichnissen in der System-Python-Bibliothek des aktuellen Rechners nachempfunden sind (die beim Erstellen von Python selbst bestimmt werden). Zum Beispiel könnte `make_blib` `blib/share/` (gemeinsam genutzte Dateien) und `blib/plat-i86-linux/` (architekturabhängige Dateien) erstellen. Es könnten auch Verzeichnisse für Dokumentation vorhanden sein, z. B. `blib/man/` für Unix-Style-Manpages, `blib/info/` für GNU-Info-Dokumentation und/oder `blib/html/` für (Sie haben es erraten) HTML-Dokumentation.

build_py

Führt `make_blib` aus; kopiert `.py`-Dateien in das "gemeinsam genutzte" `blib`-Verzeichnis (oder Unterverzeichnisse davon, wenn sie zu Paketen gehören) und kompiliert sie in `.pyc`- und `.pyo`-Form.

build_extensions

Führt `make_blib` aus; kompiliert zusätzliche C-Dateien (die, die selbst keine Erweiterungsmodule bereitstellen, aber für die zu erstellenden Erweiterungen benötigt werden); kompiliert Erweiterungs-C-Dateien; linkt zusätzliche und Erweiterungs-C-Dateien (zusammen mit allen benötigten externen Bibliotheken), um dynamische Bibliotheken (z. B. `.so`-Dateien für Unix, DLLs für Windows usw.) im architekturabhängigen `blib`-Verzeichnis zu erstellen.

build_doc

Verarbeitet Dokumentation in ein installierbares Format irgendwo unter `./blib`, z. B. im roff-Format erstellte Manpages, GNU Info, HTML, Windows-Hilfe usw. Könnten die gewünschten Dokumentationsformate bei der Erstellung von Python selbst bestimmt werden (und natürlich wäre die Python-Dokumentation in diesem Format an derselben Stelle verfügbar, an der sich die Modul-Dokumentation sammelt)?

build

Führt `build_py`, `build_extensions` und `build_doc` aus. (Natürlich tut keine dieser Operationen etwas, wenn die entsprechenden Eingaben nicht vorhanden sind.)

dist

Erstellt eine Quellverteilung ...

bdist

Erstellt eine Build-Distribution ...

testen

Sucht nach der Testsuite und führt sie aus. Eine mögliche Methode zur Definition einer Testsuite: Legen Sie eine Reihe von Skripten in einem vordefinierten Unterverzeichnis der Quellverteilung ab; diese werden dann mit den gemeinsam genutzten und architekturabhängigen `blib`-Verzeichnissen, die dem Python-Bibliotheks-Suchpfad hinzugefügt wurden, ausgeführt. Zum Beispiel könnte der `test`-Befehl nach `test/*.t` suchen, jedes Skript nacheinander ausführen und seine Ausgabe interpretieren, um festzustellen, ob diese Testreihe erfolgreich war oder fehlschlug.

install

Kopiert `.py`-, `.pyc`- und `.pyo`-Dateien in das gemeinsam genutzte Installationsverzeichnis (das standardmäßig der site-spezifische Bereich des Python-Systembibliotheksbaums wäre); kopiert dynamische Bibliotheken (shared objects oder DLLs) in das architekturabhängige Installationsverzeichnis; kopiert verarbeitete Dokumentation (manpages, Info-Dateien, was auch immer) in das Dokumentationsinstallationsverzeichnis. (Vielleicht sollte dies in `install_py`, `install_extensions` und `install_doc` aufgeteilt werden?)