PHP-Packages: Wie schön könnte es sein, wäre da nicht PEAR…
Kommentare

Phil Sturgeon erklärt in seinem Blog, wie hilfreich Packages in der PHP-Entwicklung sein können. Da PEAR seiner Meinung nach völlig unbrauchbar ist, stellt er eigene Ideen vor, wie sich durch smarte

Phil Sturgeon erklärt in seinem Blog, wie hilfreich Packages in der PHP-Entwicklung sein können. Da PEAR seiner Meinung nach völlig unbrauchbar ist, stellt er eigene Ideen vor, wie sich durch smarte Paketverwaltung Klassen wiederverwenden lassen und Abhängigkeiten automatisch erkannt werden.

Derzeit setzen viele Frameworks auf unterschiedliche Lösungen des Paket-Managements, um PEAR zu umgehen. Und Pakete bzw. Repositorys heißen überall anders: Beim CodeIgniter heißen sie Sparks, bei FuelPHP Cells, bei Laravel Bundles, bei CakePHP The Bakery und im Zend Framework 2 Modules. Framework-übergreifend betrachtet fällt auf, dass in etlichen der Pakete dieselben Funktionalitäten stecken, also viel Redundanz am Markt herrscht. Sturgeon fragt hier: „Warum sitzen wir hier herum und bauen identische Lösungen, forken sie uns zu und pflegen separate Code-bases, während wir Projekte fertigstellen könnten?“

Die Alternative soll hier der Composer mit seinem Repository Packagist sein. Die Idee ist dieselbe wie hinter Node Package Manager und Bundler / RubyGems. Dateien und Klassen werden damit im PSR-0-Standard abgelegt. Die so standardisierten Pakete lassen sich schnell für jedes Framework zuschneiden, dort weiterentwickeln und bei Bedarf wieder für alle im Packagist zusammenführen.

Der FuelPHP-Autoloader 2.0 etwa soll sowohl auf eigene Repositorys zugreifen können, als auch den Packagist nach generischen (PSR-0-kompatiblen) Paketen absuchen. Die paar Sekundenbruchteile Wartezeit seien laut Sturgeon in Anbetracht der ersparten Entwicklungszeit gut zu verschmerzen.

Im anschließenden Kommentarteil haben sich Dutzende Web-Entwickler zu Wort gemeldet. Hauptkritikpunkt ist der Ansatz, dass man die Paketverwaltung mit Mitteln wie dem Packagist zentralisieren würde, was bei einem Dienst-Ausfall einen Schwachpunkt darstellen kann. Später wird dieser Punkt entkräftet, da jeder mit dem Composer sein eigenes Repository nutzen kann. Lieber solle man die Pakete mit Phix standardgerecht gestalten und trotzdem dezentral verwalten, sagt ein anderer.

Composer ist nach eigener Aussage kein Package-Manager. Stattdessen will er als Abhängigkeits-Verwaltung (Dependency Management) bezeichnet werden. Auf Projekt-Basis zurrt er die richtigen Pakete zusammen, findet Abhängigkeiten und installiert alles in einem Rutsch, sodass es funktioniert. Fertig ist das Un-Framework. Darüber hinaus werden sämtliche Pakete im Packagist auch auf GitHub gemirrort, wo sie durch Forks und Pull Requests kontinuierlich verbessert werden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -