Was ist Composer?

Com
poser
ist ein Dependency Management Tool für PHP, zu vergleichen mit Node’s NPM oder Ruby’s Bundler. Das heisst, Composer löst Abhängigkeiten eines Projekts zu anderen Implementierungen (bspw. Libraries, Tools, Frameworks, etc.) auf. Ob es sich dabei um interne (eigene) oder externe Abhängigkeiten handelt, spielt keine Rolle. Composer ist somit eine mögliche Lösung für folgende Problemstellung:

  • Sie haben ein Projekt mit Abhängigkeiten zu anderen Paketen (z.B. Symfony 2).
  • Dieses Projekt hat wiederum Abhängigkeiten zu anderen Paketen (z.B: Twig).
  • Sie deklarieren die Abhängigkeiten, die Sie benötigen.
  • Composer findet die entsprechenden Pakete und lädt sie in Ihr Projekt herunter.

Umfeld

Composer wird überall eingesetzt, wo modularisierter bzw. paketisierter Code zum Einsatz kommt. Das berühmteste Beispiel ist wohl das Symfony 2 Framework, welches komplett per Composer installiert werden kann und alle Abhängigkeiten selbständig auflöst. Es gibt natürlich auch andere Dependency-Manager bzw. Paketierungstools im PHP-Umfeld. Die zweifellos bekanntesten sind PEAR (PHP Extension and Application Repository) und die daraus entstandene PECL (PHP Extension Community Library), auf die ich hier jedoch nicht weiter eingehen möchte.

Anwendung

Composer besteht im Wesentlichen aus den zwei Dateien composer.phar und composer.json. Dazu kommt noch die composer.lock, welche fürs grundlegende Verständnis von Composer jedoch nicht wichtig ist. Dokumentation composer.lock

composer.phar

Dieses phar-Archiv beinhaltet die ganze Applikation, welche mit verschiedenen Parametern angesprochen werden kann. So werden beispielsweise mit dem Befehl php composer.phar install definierte Abhängigkeiten installiert oder mit php composer.phar update aktualisiert. Die einzigen Voraussetzungen, die dafür erfüllt sein müssen, sind PHP 5.3.x (CLI) und eine funktionierende Internetverbindung.

Eine kurze Auflistung der wichtigsten Parameter mit Beispiel und deren Dokumentationslink:

php composer.phar install
Installiert die definierten Abhängigkeiten.
http://getcomposer.org/doc/03-cli.md#init

php composer.phar update [vendor/package] [vendor/package2]
Sucht nach neueren Versionen der Pakete und installiert diese.
http://getcomposer.org/doc/03-cli.md#update

php composer.phar create-project doctrine/orm [path] [2.2.0]
Kreiert ein neues Projekt auf der Basis eines existierenden Pakets.
http://getcomposer.org/doc/03-cli.md#create-project

composer.json

In der Datei composer.json werden gleichermassen Abhängigkeiten sowie Paketinformationen gespeichert. So kann ein Softwareprojekt gleichzeitig ein Paket sein zu dem Abhängigkeiten aufgebaut werden, selber jedoch weitere Abhängigkeiten haben. Ein schönes Beispiel dafür ist das Doctrine 2 ORM (doctrine/orm), welches wiederum Abhängigkeiten zu doctrine/dbal und symfony/console hat. So kann man beliebig weitermachen, weshalb z.B. doctrine/dbal wieder eine Abhängigkeit zu doctrine/common hat.

Konfiguration

Wie bereits erwähnt, liefert die composer.json Konfigurationsdatei des Doctrine 2 ORM ein sehr schönes Beispiel, welche ich deshalb zur Erklärung der einzelnen Konfigurationsmöglichkeiten aufgreifen möchte.

Beispiel

Paketdaten (“name” – “authors”)

Der Name des Pakets besteht normalerweise aus Vertreiber(Vendor)/Paketname also in diesem Beispiels doctrine/orm. Bei den meisten Projekten, die auf GitHub gehostet sind, ist der Vertreibername gleich wie der GitHub Username bzw. Organisation und der Paketname wiederum identisch mit dem Namen des Repositories. Die Attribute ”type”, “description”, “keywords”, “homepage”, “license” und “authors” sind – so glaube ich – selbsterklärend.

Package Links (“require”, “suggest“, conflict”, “provide”)

Da wir den langweiligen Teil der Konfiguration nun hinter uns gelassen haben, können wir uns auch gleich dem Kernpunkt, nämlich den Abhängigkeiten widmen.

Das wichtigste der vier Attribute –  deren Struktur immer aus Name/Version oder Name/Beschreibung besteht – ist “require”. Wie im Beispiel schön ersichtlich, können an dieser Stelle sog. “Environment Requirements”, also Umgebungs- bzw. Systemabhängigkeiten definiert werden. Im oberen Beispiel wird also mindestens PHP 5.3.2 mit installierter PDO-Extension vorausgesetzt. Hier ist zu beachten, dass Composer diese Voraussetzungen zwar prüft, jedoch nicht selbständig auflösen kann. Im selben Block werden auch Paketabhängigkeiten definiert. Hierbei ist der Paketname in der selben Form wie er im “name”-Feld der Zielkonfiguration steht, einzutragen. Bei der Versionierung kann mit Aliases (z.B: dev-master) und Wildcards (z.B. 3.2.* oder 3.*) gearbeitet werden.

Wird ein Paket nicht direkt vorausgesetzt, jedoch empfohlen, wird es im “suggest”-Attribut vermerkt. Composer installiert dann das Paket nicht automatisch nach, gibt jedoch auf der Konsole eine Empfehlung aus.

Autoloading (“autoload”)

Nachdem Composer alle benötigten Komponenten installiert hat, kümmert es sich auch gleich um das nächste Problem. Im Attribut “autoload” können Verzeichnisse gelistet werden, für welche nach der Installation ein Autoload-Register generiert werden soll. Die Struktur ist im offiziellen Beispiel von Composer etwas einfacher ersichtlich als im Doctrine-Beispiel:

Weitere (“bin”, “extra”)

Im “bin”-Attribut werden auf der Konsole ausführbare Dateien gelistet, welche dann im globalen bin-Verzeichnis der Webapplikation “versymlinkt” werden. Mithilfe des “extra”-Attributs können Daten an die Installationsscripts übergeben werden.

Packagist

So heisst das Standard Repository von Composer. Auf der Webseite http://packagist.org/ können sowohl Paketinformationen eigesehen, wie auch eigene übermittelt werden. Natürlich setzt die Verwendung des Packagist-Repositories Open Source Code voraus, da die Pakete für jedermann einsehbar sind. Wer das nicht möchte, kann sich mit Hilfe von Packagist (Applikation) oder Satis auch eigene Repositories hosten.

Persönliches Fazit

Composer kann bei nahezu jedem, auch noch so kleinem PHP-Projekt eingesetzt werden. So lernt man seinen Code modular zu konzipieren (was beispielsweise auch bei eZ Publish 4 Extensions möglich wäre), ist bei externen Abhängigkeiten für die Zukunft gerüstet und muss sich zudem nicht mehr um die Autoloads kümmern.

Dass Composer auch in der PHP-Community breiten Anklang findet, sieht man beispielsweise beim Symfony 2 oder FuelPHP Framework, welche bereits die komplette Installation über Composer anbieten. Durch viele Zusatzfeatures wie Konfliktmanagement, Script-Hooks und Custom Repositories kann der leichtgewichtige Dependency-Manager auch gut mit ausgewachsenen Paketmangern wie RPM, APT oder PEAR mithalten.

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *