Serendipity und Composer

[falk]

Hallo,

der erste Schritt ist getan: Ich habe Composer in S9y 2.0 integriert. Zunächst im Branch unter https://github.com/fadoe/Serendipity/tree/2.0-composer. Eine kurze Anleitung steht in der README.

Derzeit werden nur Simplepie und Smarty über den Composer geladen. Später soll er auch das Laden anderer Libraries und der S9y-Dateien übernehmen.

Diese Funktion merge ich in S9y 2.0, wenn der 1.7-2.0-Merge ordentlich funktioniert.

Viele Grüße,

Falk

[yellowled]

Diese Funktion merge ich in S9y 2.0, wenn der 1.7-2.0-Merge ordentlich funktioniert.

Können Malte und ich im 2.0-branch irgendetwas tun, um das zu vereinfachen?

YL

[Timbalu]

Falk, auch wenn du mich als Mitentwickler gar nicht auf deinem Plan hast - STOP!

Soweit ich das sehen kann, geht es bei diesem Composer um einen automatischen (Nach) Lader, der die eingebundenen Pakete wie in diesem Fall Smarty (*), Simplepie, Pear und noch zukünftig einiges mehr, also quasi alles was irgendwie in einem eigenen Gehege gehalten wird, automatisch zur Installation einbindet und nachlädt.

Das ist im Grunde eine Designfrage, ob man nur ein systemeigenes Grundgerüst zur Verfügung stellt und dann per Automatik die notwendigen Bibliotheken - im Vertrauen darauf, dass diese sauber gepflegt werden - per Einzelfall einbindet.

Man verliert aber einerseits die Möglichkeit wachsam in Verantwortung für das eigene System einzugreifen und zb Bibliotheken Releases zu patchen, andererseits muss man der automatischen Einbindung solcherart vertrauen, dass sie jederzeit stattfindet (und in Kauf nimmt, das Services manchmal Schluckauf haben oder nicht erreichbar sind). Auf alle Fälle gibt man Verantwortung aus der Hand.

Der einzige Vorteil, den ich bis jetzt erkennen kann, ist, dass das Serendipity Release zip damit voraussichtlich etwas kleiner wird.

Ich kann nicht erkennen, dass das Neue solcherart Vorteile bringt, das man einen solchen Designwechsel wirklich vertreten kann.

(*) btw, wir sind schon einen weiter..

[mattsches]

Man verliert aber einerseits die Möglichkeit wachsam in Verantwortung für das eigene System einzugreifen und zb Bibliotheken Releases zu patchen, andererseits muss man der automatischen Einbindung solcherart vertrauen, dass sie jederzeit stattfindet (und in Kauf nimmt, das Services manchmal Schluckauf haben oder nicht erreichbar sind). Auf alle Fälle gibt man Verantwortung aus der Hand.

Sehe ich nicht so, denn du kannst in der composer.json genau die Version einer externen Bibliothek definieren, die eingebunden werden soll. Momentan passiert das eben manuell, d.h. einer lädt eine neue Version einer Lib herunter, überschreibt die alte Version, committed alles nach git. Mit Composer änderst du einfach die Versionsnummer in der composer.json.

Der einzige Vorteil, den ich bis jetzt erkennen kann, ist, dass das Serendipity Release zip damit voraussichtlich etwas kleiner wird.

Auch das würde, wenn ich das richtig verstehe, anders laufen. Das Build-Skript, welches das Release-ZIP erstellt, müsste die externen Libs auschecken und in das ZIP mit hineinpacken. Bei Problem mit Github o.ä. könnte einfach kein Release erstellt werden (oder das müsste manuell erledigt werden).

Entwickler müssten sich natürlich Composer installieren (aber PHP-Entwickler sollten das IMHO sowieso unbedingt machen), und YL können wir das beibringen *duck*

[Timbalu]

Auch das würde, wenn ich das richtig verstehe, anders laufen. Das Build-Skript, welches das Release-ZIP erstellt, müsste die externen Libs auschecken und in das ZIP mit hineinpacken. Bei Problem mit Github o.ä. könnte einfach kein Release erstellt werden (oder das müsste manuell erledigt werden).

Ja, so herum wäre dieser Teil schon anders zu bewerten... Allerdings frage ich mich, warum dann das init_autoload Script in der serendipity_config.inc.php eingebunden ist?

[falk]

Können Malte und ich im 2.0-branch irgendetwas tun, um das zu vereinfachen?

YL

Ja, könnt ihr. Am einfachsten ist wenn ihr euch mein Serendipity-Repo clont, die Merges durchgeht und Fehler behebt und Pull-Requests schickt. Die Sourcen von 1.7 und 2.0 waren doch schon sehr weit auseinander, weshalb ich bei einigen Merges mein Gefühl beanspruchen musste.

@mattsches: Vielen Dank für deine Antwort. Du hast vollkommen recht. Wir können direkt die Version tagen die wir brauchen. Notfalls clonen wir die benötigten Repos in das Serendipity-Projekt. Ich sehe noch einen Vorteil: Es werden nicht mehr die Original-Libs geändert. Werden Änderungen notwendig, müssen dafür halt Pull-Requests an das jeweilige Projekt gestellt werden.

[mattsches]

Allerdings frage ich mich, warum dann das init_autoload Script in der serendipity_config.inc.php eingebunden ist?

Wenn ich das richtig verstehe, macht ein eventuelles Build-Skript für eine neue Version nichts anderes als ein PHP-Entwickler, der sich S9y auscheckt, nämlich erstmal `composer install` ausführen, um die externen Bibliotheken zu installieren und Abhängigkeiten aufzulösen.

Dabei erstellt Composer einen angepassten Autoloader, der Informationen darüber enthält, wo die Libs liegen. Jede Lib kann eine eigene `composer.json` mitbringen, in der steht, wo die Lib hininstalliert werden soll. Composer kümmert sich darum, dass alles gefunden wird. Beispiel Smarty (unter autoload/classmap stehen drei Pfade zu Files).

Dazu muss natürlich der Composer Autoloader so früh wie möglich geladen werden, in unserem Fall in der serendipity_config.inc.php. Ich denke, das ist okay so.

Viele Grüße
- Mattsches

[Timbalu]

Dazu muss natürlich der Composer Autoloader so früh wie möglich geladen werden, in unserem Fall in der serendipity_config.inc.php. Ich denke, das ist okay so.

Hmm, den "composter" itself zu verstehen ist ja einfach... Aber, ich denke nicht, dass das so OK ist.
Denn wenn das - wie du selber sagst - ein composer nur für das Release Script (also praktisch für Garvin) da ist - befände sich init_autoload im release script, also eines von Garvins automatisierten Skripten, wahrscheinlich s9y_release.sh (oder dessen Nachfolger). Die Datei serendipity_config.inc.php wird doch sehr wahrscheinlich dabei gar nicht aufgerufen und hat prinzipiell nur in Nach-Release-Installationen zu tun.

Wenn dann so ein s9y_release.sh den composer autoloaded, dann trunk/composer.json aufruft und in trunk/serendipity/"libs"... installiert, hätten wir die Smarty Situation. Nur, das Smarty eben (als LIB) auch dafür gemacht ist, irgendwo eingebunden zu werden und dafür das composer.json bereitstellt, weil irgendwann vor einem Jahr es jemand nötig fand "to install Smarty as a dependency in Symfony projects".

Wir sind daher eher in der Situation des Letzteren. Soll das Serendipity composer.json nun eben auch von anderen benutzt werden können, um sich ein Serendipity mit eigenen Wünschen zusammenzustellen, und darauf läuft es doch eigentlich hinaus, sonst hätte Garvin selbst das schon als ein Hilfsmittel im Release Prozess für sich benutzen wollen und nicht ein anderer, so erhebt sich weiterhin das Argument, dass damit Verantwortung abgegeben wird und Garvin als Maintainer nicht mehr die volle Kontrolle besitzt. Es wäre wie gesagt prinzipiell eine Designfrage, die die Historie und Betreuung eines Projektes berücksichtigt. Im Falle von Serendipity haben wir eine klare Hierarchie, die darauf basiert das Garvin in Verantwortung für das Projekt etwas freigibt oder nicht. Das war bis jetzt sehr erfolgreich. Ich sehe daher auch keinen Grund das zu ändern, ...besonders da keinerlei Anzeichen von Egomanie zu verzeichnen sind.

Das es sich bei der vorgeschlagenen Änderung nun um einen solchen schleichenden Prozess handelt, scheint mir auffällig, denn nur um dem Serendipity Nutzer die Möglichkeit zu geben im Laufe eine Release Lebenszyklus automatisiert libs zu erneuern, gäbe es sicherlich auch gute Argumente, warum dies per se nicht so einfach gemacht werden sollte. Da redet man m.E. von sehr wenigen Leuten, die natürlich sowieso auch schon selbst in der Lage wären, Smarty, Pear oder Ähnliches schnell manuell oder per shell auszutauschen.

Was also bleibt der eigentliche Sinn und Zweck dieses "Konzept-Designänderungs" Vorschlags...!? Darauf hätte ich gerne eine fundierte Antwort!

[onli]

Ok. Fundierte Antwort folgt.

Was wir derzeit mit bundled_libs wie Smarty machen ist unverantwortlich, unnötig und unnötig aufwändig, zumindest wenn ein System wie composer existiert und funktioniert. Wir bündeln die externen Libs in Serendipity, passen sie teilweise an und updaten sie selten. Dadurch entstehen nicht nur potentiell Sicherheitslücken, die wir übersehen wenn nicht gut aufgepasst wird, sondern es entstehen Situationen, in denen die neue Version der Lib wegen den s9y-Änderungen nicht genutzt werden kann. Wir schaffen also ein Paralleluniversum der PHP-Libs , das noch dazu den Plugins die neuen Funktionen unterschlägt.

Und ganz nebenbei ist es viel mehr Arbeit, selbst wenn man mit Disziplin die Änderungen sein lässt und regelmäßig updatet.

Bei composer will ich (und ich glaube: wir) das folgende Modell haben (und ich glaube, dass das mit dem autoloader so funktioniert): Grundsätzlich hat Serendipity keine Libs im Repository. Vor einem Release oder vor einer Installation der Entwickler müssen mit Composer diese gezogen werden. Garvins würde also nur noch die Dependencies in Composer konfigurieren müssen und diesen dann die Libs installieren lassen.
Und wenn ich das richtig verstehe lädt autoloader diese Libs, die von composer gezogen wurden.

Nebenbei: Ich glaube nicht, dass Garvins Rolle hier angegriffen wird und verteidigt werden muss. Das Feature ist ja abgesprochen, und derzeit noch im eigenen Branch.
Gruß

[mattsches]

Stimme onlis Antwort voll zu.

Noch mal zur Änderung von falk. Er hat im Prinzip

Code: Select all

$new_include = ($serendipity['use_PEAR'] ? $old_include . PATH_SEPARATOR : '')
             . S9Y_INCLUDE_PATH . 'bundled-libs/' . PATH_SEPARATOR
             . S9Y_INCLUDE_PATH . 'bundled-libs/Smarty/libs/' . PATH_SEPARATOR
             . $serendipity['serendipityPath'] . PATH_SEPARATOR
             . (!$serendipity['use_PEAR'] ? $old_include . PATH_SEPARATOR : '');

aus der serendipity_config.ini.php rausgeworfen und durch den Composer Autoloader ersetzt.

Übrigens: Es gibt Mittlerweile eine ganze Menge Dienste, die auf Composer (und GitHub) aufbauen und ganz nützlich sind. Z.B. VersionEye, das Entwickler automatisch benachrichtigt, wenn veraltete Bibliotheksversionen verwendet werden (vgl. onlis Post). Oder TravisCI, ein Continuous Integration System, das automatisiert die u.a. Unit Tests durchführt, sogar unter verschiedenen PHP-Versionen.

Mit der Umstellung auf Github haben wir schon den ersten Schritt dahin getan, von solchen Diensten profitieren zu können. Composer ist IMHO der logische nächste Schritt.

@Timbalu: Trotzdem danke für deine kritischen Beiträge. Composer nur einzuführen, weil es gerade "hip" ist, hielte ich auch für falsch. Aber es bringt uns insbesondere im Hinblick auf Aktualität und Sicherheit viele Vorteile.

[mattsches]

Und was natürlich auch cool wäre, wenn wir auch unsere Plugins bzw. Spartacus auf Composer umstellen können. Also nicht für die Plugins selbst, sondern wenn die Plugins wiederum auf externe Bibliotheken zurückgreifen. Ich denke da an Plugins wie Twitter, Markdown o.ä.

Ich weiß zwar gerade nicht genau, was wir dafür alles tun müssten, aber ich glaube das hier sollten wir uns diesbezüglich mal ansehen.

[garvinhicking]

Hi!

Ich habe bislang noch nicht mit Composer gearbeitet.

Verstehe ich das richtig, dass in diesem Fall jemand unseren Github Kern nicht einfach per git checkout oder git zip download mehr herunterladen kann und s9y aktualisieren?

Nicht jeder s9y nutzer kann composer ausführen (weil oft kein SSH oder so zur Verfügung steht). Was machen diese Personen?

Oder ist es so gedacht, dass composer für entwickler ansprechbar ist und wir die ganzen sourcen dann auch so in unserem github repository haben, und wir mit composer lediglich diese repos leider aktualisieren können und sonst für alle Benutzer alles beim selben bleibt, also ich gar kein release shell script anpassen muss?

Es würde mich freuen, wenn Falk, Mattsches oder olni hierzu mal ein vollständiges Konzept vorlegen können wie das funktionieren wird, welche Vorteile es bringt, und welche potentiellen Nachteile entstehen könnten.

Grüße,
Garvin

[falk]

Hallo Garvin,

im Prinzip sind alle Vorteile schon genannt worden. Auch der einzige Nachteil: Keine Änderungen in den vendor-libs .

Das Deployment ist auch ganz einfach: Jeder der sich die Sourcen von github zieht weiß, wie man den Composer nutzt. Für alle anderen gibt es ein Paket von s9y.org, in dem die vendor-libs eingebunden sind. Vielleicht kann man den Installer auch so erweitern, dass er den Composer ausführt. Aber den wil ich ja sowieso mit als erstes umschreiben ...

Ich freue mich, dass es so viel Zustimmung für meine Ideen gibt. Ich hoffe diese Woche noch die ersten Refactorings auf github.com/fadoe/serendipity hochladen zu können. In meinem 2.0-Branch ist bereits der Composer-Support komplett umgesetzt.

Die composer-install kannte ich bereits. Die ist auch schon in meine Überlegungen eingeflossen. Um diese gegen Spartacus auszutauschen müsste ein kleines Frontend für den Composer geschrieben werden. Aber da die Libs vorhanden sind sollte das kein Problem sein.

Bis die Tage,

Falk

[garvinhicking]

Hi!

Das Deployment ist auch ganz einfach: Jeder der sich die Sourcen von github zieht weiß, wie man den Composer nutzt. Für alle anderen gibt es ein Paket von s9y.org, in dem die vendor-libs eingebunden sind. Vielleicht kann man den Installer auch so erweitern, dass er den Composer ausführt. Aber den wil ich ja sowieso mit als erstes umschreiben ...

Hm, das sehe ich halt nicht so. Ich finde es schon praktisch dass derzeit jeder User sich die Sourcen von Github ziehen kann und auf den Webserver schmeißen kann, und alles läuft.

Ich fände es also gut wenn man das composer-mäßig so einrichtet, dass ein s9y-dev die vendor libs via composer-backend reinziehen kann in den s9y github tree, und dann die Dateien dahin committet - dann liegen die sourcen ja auch bearbeitbar im github tree und wir haben auch den letzten Nachteil ausgemerzt und alle sind glücklich?

Kannst Du nochmal für composer-newbies wie mich beschreiben wie Du es derzeit implementiert hast? Auf https://github.com/fadoe/Serendipity/tree/2.0-composer finde ich keinen Inhalt und keine README - ich wüsste gerne wie da der konkrete Workflow aussieht, und welche Änderungen es wo wie gibt (d.h. ein patch/diff mit den composer-relevanten änderungen wäre auch toll?)

Viele Grüße,
Garvin

[yellowled]

Jeder der sich die Sourcen von github zieht weiß, wie man den Composer nutzt.

Ich bin der lebende Gegenbeweis.

YL