KingCrunchs kleine Welt

Update 1: 12.01.2010 13:00; Siehe Unten

Will man selbst PHP-Bibliotheken veröffentlichen, steht man vor einem schlichten Problem: Wie? Die übliche (und einfachste) Antwort ist die manuelle Lösung, bei der man sich das Paket selbst herunterladen und entpacken muss. Dabei gibt es für PHP schon seit Jahren mit PEAR eine Paketverwaltung, die allerdings im Laufe der Zeit etwas in Vergessenheit geriet. Third-party Bibliotheken sind oft effektiver, viele PEAR-Pakete werden garnicht oder nur noch sporadisch weiter entwickelt, und letzten Endes gilt das dazugehörige CLI-Tool als komplex. Letzteres gilt eigentlich zu Unrecht, denn als einfacher Anwender braucht man nur die 2 Kommandos channel-discover und install.

Will man nun allerdings für den PEAR-Installer Pakete bereit stellen, sieht man sich zwangsläufig dazu verpflichtet selbst einen PEAR-Server, wie Pirum bereit zu stellen. Mal abgesehen davon, dass das nicht für jeden möglich ist, führt das auch dazu, dass jeder seinen eigenen, verteilten Server bereit stellt, der womöglich nur ein einziges Paket enthält. Von einem Verzeichnis kann hier nicht mehr gesprochen werden. Genau das könnten jetzt zwei Dienste entgegen wirken:
Pearhub (Introductory Blog Post) und Pearfarm (Announcing Pearfarm). Da beide noch sehr jung sind, kann man zwar keine Wunder erwarten, aber endlich mal gibt es sowas überhaupt für PHP-Entwickler, die nicht selbst einen Server aufsetzen wollen oder können.

Pearhub

Pearhub ist ein Ein-Mann-Projekt und so auch sehr einfach aufgebaut. Wie der Name schon andeutet (“Github“) ist dieser Dienst sehr eng mit Versionierungssystemen verknüpft, was auch der einzige Weg ist neue Paket-Releases zu veröffentlichen. Pearhub holt sich dabei die Dateien der Releases selbstständig aus beliebigen Git- oder SVN-Repositories, indem es diese nach Versions-Tags — also Tags mit Namen der Form “vX.Y.Z” oder “X.Y.Z” — absucht, von dort bestimmte Verzeichnisse zusammen sammelt und zusammen mit Properties, die bei der Erstellung des Pakets angegeben wurden, das Paket schnürt.

Aus Entwicklersicht ist dies auch schon alles. Man meldet sich mit einem OpenID-Benutzernamen an [1], erstellt ein Paket an, wobei man dort bereits Lizenz, Maintainer, Dependencies, usw für alle Pakete angibt. Danach wartet man, falls es schon versionierte Tags gibt. In Zukunft braucht man sich garnicht weiter darum kümmern.

Aus Anwendersicht ist es fast nocht einfach: Man muss den Channel nur einmal “erkunden” (pear channel-discover pearhub.org) und kann dann beliebige dort registrierte Pakete mit “pear install pearhub/PaketName” installieren. Es gibt dabei nur einen Channel, in dem alle Pakete alle Benutzer laden. Das spart das erkunden weiterer, verstreuter Channels.

Etwas störend ist, dass die Tags zwar nach eigenen Aussagen nach “Semantic Versioning” abgesucht werden, eine Version “0.5.0dev” erkannte es im Test bisher allerdings nicht. So scheint es, dass als “Status” nur “Completed” möglich ist. Zudem fehlt es an ein paar, nicht ganz unwichtigen package.xml-Properties, wie zB API-Version, optionale Abhängigkeiten, sowie einige Dependency-Arten und automatisierte Task. Die wichtigen sind allerdings alle vorhanden. Man könnte Pearhub noch vorwerfen, dass es keine Dokumentation gibt, aber die würde sich sowieso wie eine Anleitung für einen Toaster anfühlen.

Pearfarm

Pearhub dagegen wirkt fast schon traditionell. Es versucht einen ähnlichen Service anzubieten, wie die Rubygems für Ruby. Das macht Pearfarm etwas komplizierter als Pearhub, dafür aber auch mächtiger.

Als Entwickler sollte man sich trotzdem nicht abschrecken lassen, dann pearfarm gibt einen dafür ein handliches CLI-Tool an die Hand. Mit init erstellt man die “pearfarm.spec”, die man erstmal bearbeiten muss. Danach erstellt man direkt mit build das Paket, was man direkt mit push meinpaket.tar.gz hochladen kann [2]. In Zukunft muss man in der Spec-Datei nur noch die Versionsnummern anpassen.

Im Gegensatz zu Pearhub gibt es pro Nutzer einen eigenen Channel unter “benutzername.pearfarm.org”. Ein Anwender muss also jeden Benutzer einzeln “erkunden”, wenn er Pakete von verschiedenen Nutzern installieren will. Ansonsten ändert sich nichts.

Leider merkt man Perfarm schon eher einen gewissen Beta-Status an. Zum Beispiel ist als Lizenz nur die MIT-Lizenz möglich, weil die Links zu den Linzenzen fest einkodiert sind, es gibt davon aber bloss zur Zeit nur diese eine. Die Dokumentation ist ziemlich lückenhaft, was grad für die Spec-Datei etwas ungünstig ist. Ob “Ein-Channel-Pro-Nutzer” ein Nachteil ist, ist schwer zu sagen: So kann sich jeder beliebig ausleben und vielleicht eigene Bibliotheken noch etwas feiner aufteilen und mit Abhängigkeiten verknüpfen, aber einfach zum Stöbern und Installieren bei beliebigen Nutzern lädt es nicht ein.

Abschluss

Beides sind vielversprechende Dienste, die sehr unterschiedliche Wege gehen. Bei Pearhub vermisst man die Flexibilität der Spec-Dateien von Pearfarm. Andersherum vermisst man bei Pearfarm Pearhubs Automatisierung. Vielleicht gibt es irgendwann eine Zusammenarbeit , oder Einer klaut einfach geschickt vom Anderen. So wäre die Spec-Datei im VCS-Root [3] ebenso gut aufgehoben. Auf jeden Fall sollte jeder PHP-Entwickler ein Blick darauf werfen. Ein verbreitetes Paketmanagement, was auch noch auf bewährten Techniken aufsetzt, fehlt PHP mE noch.

Update 1

Entgegen meiner Aussage, mit Pearfarm sei nur die MIT-Lizenz möglich, kann man auch eigene Lizenzen setzen. Das ist allerdings ein “undocumented Feature”, was sogar der Entwickler selbst vergessen hat. Dazu muss man in der Spec-Datei die Lizens als assoziatives Array übergeben.

$spec->setLicense(array('name'=>'LGPL','uri' => 'http://www.gnu.org/licenses/lgpl.txt'));

Find ich persönlich nicht sooo elegant. Insgesamt ist der Quellcode des CLI-Tools recht spannend

[1] Übigens über Komponenten aus dem Zend Framework realisiert
[2] Vorher muss man einmalig allerdings ein pearfarm keygen einen öffentlichen SSH-Schlüssel erzeugen, den man im eigenen Account hinterlegt.
[3] Vgl zum Beispiel .gitignore, die in der Regel auch versioniert werden.