Python Distutils-SIG: Aufgaben und Arbeitsteilung

Python Distutils-SIG

Aufgaben und Arbeitsteilung

Auf der Entwicklerkonferenz "Seventh International Python Conference Developer's Day" wurde im Rahmen der Sitzung "Extension Building Considered Painful" eine Aufzählung der Aufgaben vorgenommen, die für die Entwicklung, Verteilung und Installation von Python-Modulen notwendig sind. Wir haben uns auf eine grobe Einigung über die notwendige Arbeitsteilung geeinigt, um jedes Distributions-/Installationssystem konzeptualisieren zu können, und kamen auf eine vorgeschlagene Benutzeroberfläche. Dieses Dokument beschreibt die Aufgaben und die Arbeitsteilung; die vorgeschlagene Benutzeroberfläche wird an anderer Stelle beschrieben.

Drei Rollen wurden identifiziert: der Entwickler, der Packager und der Installer (in einem Sinne der Endbenutzer des Systems; ich bleibe bei "Installer", da er nicht der *einzige* Benutzer ist). Offensichtlich gibt es Überschneidungen in diesen Rollen; einige Aufgaben müssen sowohl vom Entwickler als auch vom Packager erledigt werden, einige von allen dreien, usw. Ich werde versuchen, jeder Aufgabe eine "primäre" Rolle zuzuordnen und sie unter anderen Rollen wieder zu erwähnen, wo sie ebenfalls auftauchen.

Aufgaben des Entwicklers

Die primären Aufgaben des Entwicklers sind

entwickeln: das/die Modul(e) schreiben und pflegen
dokumentieren: das/die Modul(e) dokumentieren (beachten Sie, dass das Problem der Dokumentation von Python-Modulen auf standardisierte Weise außerhalb des Zuständigkeitsbereichs der Distutils-SIG liegt; wenn jedoch ein solcher Standardweg zustande kommt, sollten wir tun, was wir können, um ihn zu unterstützen, wie z.B. einfache Schnittstellen zu den Standard-Dokumentationswerkzeugen bereitzustellen)
Test-Suite bereitstellen: Code schreiben, der (theoretisch) jeden Teil des/der Module(s) testet und Erfolg oder Misserfolg auf standardisierte Weise meldet (die Rolle der Distutils wäre, eine standardisierte Schnittstelle zum Ausführen der Test-Suite und zur Interpretation ihrer Ergebnisse bereitzustellen)
Installationswerkzeug bereitstellen: derzeit zeitaufwändig, fehleranfällig und einfach nur mühsam (und inkonsistent über Entwickler hinweg erledigt): das Problem, das die Distutils-SIG lösen soll! Die Distutils sollten dieses Installationswerkzeug sein; alles, was der Entwickler normalerweise bereitstellen muss, sind Informationen, die den Distutils helfen, ihre Arbeit zu erledigen
Quellcode-Distribution erstellen: nicht viel mehr als das Tarren eines Teils des Quellcode-Baums, aber – da die Distutils Informationen wie Name, Versionsnummer usw. haben werden – kann mit ihrer Hilfe trivial gemacht werden

Der Entwickler muss die Software im Laufe der Entwicklung auch wiederholt *bauen*, was bedeutet, dass die Schnittstelle für den Bau sowohl für Installer (möglicherweise naive Endbenutzer) als auch für Entwickler ausgelegt sein muss. (Dies spricht für zwei Bau-Schnittstellen.) Die Erstellung einer Quellcode-Distribution könnte als Aufgabe eines Packagers betrachtet werden, wird aber fast immer vom Entwickler erledigt, der seinen "Packager"-Hut trägt; andererseits kann der Entwickler diesen Hut wieder aufsetzen, um eine gebaute Distribution für seine bevorzugte(n) Plattform(en) zu erstellen, aber das habe ich unten unter den Aufgaben des Packagers zusammengefasst.

Aufgaben des Packagers

gebaute Distribution erstellen: eigentlich der einzige Grund für die Existenz des Packagers: Dies besteht darin, die Quellcode-Distribution herunterzuladen, das/die Modul(e) zu bauen und aus dem Ergebnis des Baus eine neue herunterladbare Ressource zu erstellen

Zusätzlich zum Bauen der Software sollte der Packager sie wahrscheinlich testen, bevor er die gebaute Distribution erstellt.

Aufgaben des Installers

bauen

Quelldateien in eine für die Installation vorbereitete Form umwandeln. Dies kann letztendlich Folgendes beinhalten

.py-Dateien in einen Mockup-Installationsbaum kopieren
.py-Dateien zu .pyc und .pyo kompilieren
C-Erweiterungen kompilieren und linken, wobei die Shared Objects in den Mockup-Installationsbaum platziert werden
Dokumentation verarbeiten (z.B. Erstellung von *roff-Dateien für Unix-Manpages, Info-Dateien für das GNU-Info-System und/oder HTML-Dateien für webfreundliche Dokumentation)

testen

die vom Entwickler bereitgestellte Test-Suite ausführen und sicherstellen, dass das/die Modul(e) alle Tests bestehen

installieren

den Mockup-Installationsbaum in einen vorhandenen Python-Bibliotheksbaum kopieren (nicht unbedingt die System-Python-Bibliothek – könnte im Home-Verzeichnis eines Benutzers oder in einem temporären Verzeichnis liegen)

Beachten Sie, dass diese davon ausgehen, dass der Installer mit einer Quellcode-Distribution arbeitet – wenn dies immer der Fall ist, hat der Packager seine Zeit verschwendet, und das wollen wir nicht. Die Installation von gebauten Distributionen sollte trivial sein, aber es gibt einige ungelöste Bedenken: wie gehen wir mit dem Unterschied zwischen "intelligenten" und "dummen" gebauten Distributionen um (z.B. RPM oder Wise Installer vs. eine einfache .tar- oder .zip-Datei)? sollte die Test-Suite ausgeführt werden, wenn eine gebaute Distribution installiert wird, und wenn ja, wie?