Serendipity Forums

yellowled wrote:

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

Ich bin der lebende Gegenbeweis.

Dito. Ich drück nämlich einfach auf den ZIP-Knopf

yellowled wrote:

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

Ich bin der lebende Gegenbeweis.

Das stimmt nicht, glaub ich. Da kommt selbst in der derzeitigen Implementation (bzw der letzten, die ich sah) eine entsprechende Fehlermeldung, die den einen Befehl ausgibt, den man ausführen müsste. Das könntest du.

Und Bernd genauso.

onli wrote:Da kommt selbst in der derzeitigen Implementation (bzw der letzten, die ich sah) eine entsprechende Fehlermeldung, die den einen Befehl ausgibt, den man ausführen müsste.

Ich will gar nicht bezweifeln, dass ich das könnte. Ich würde sogar der Logik „wer Sourcen aus git zieht, muss mit sowas umgehen können“ grundsätzlich zustimmen.

Ich sage nur: Man sollte gucken, ob es nicht einen simpleren Weg gibt. Letztlich wollen wir es ja auch anderen Entwicklern so leicht wie möglich machen, schnell einzusteigen.

YL

Hi!

Das stimmt nicht, glaub ich. Da kommt selbst in der derzeitigen Implementation (bzw der letzten, die ich sah) eine entsprechende Fehlermeldung, die den einen Befehl ausgibt, den man ausführen müsste. Das könntest du.

Es gibt eine riesige Kundschaft an Leuten die einen 1&1, DomainFactory oder was auch immer Webserver ohne SSH Zugang haben. Die können das nicht. Das ist eine große Zielgruppe. Es ist eher die Ausnahme, dass jemand SSH-Zugang zu seinem Webspace hat.

Viele Grüße,
Garvin

Hi Garvin
Aber die müssten das ja auch nicht tun :) In Releases wären die sowieso dabei, da waren wir uns - glaube ich - alle einig.

Wobei es für mich völlig ok ist, wenn die bundled_libs mit im git liegen. Wir brauchen die ja nicht nur deswegen anpassen, weil wir es können. Ich will den Punkt nur nicht überbewerten.

Hi!

onli wrote:Hi Garvin
Aber die müssten das ja auch nicht tun In Releases wären die sowieso dabei, da waren wir uns - glaube ich - alle einig.

Geht aber halt ja auch drum die Zwischenversionen nicht zu erschweren, finde ich. Wir würden damit einen großen Testerkreis ausschließen für die man immer mühsam neue Releases erstellen muss. Derzeit kann man schon easy sagen "nimm halt den aktuellen Trunk".

Zudem erhöht es den Aufwand wenn Leute wie ich einen github checkout auf ihrem server laufen lassen und einfach immer nur "git pull" per cronjob laufen lassen. Die müssten dann ständig auch den Stand des Composers prüfen, oder?

Für mich wäre es also schon sehr wichtig, die libs mit im git zu haben, und composer das da reinschreiben/updaten zu lassen. Wunschfall wäre es natürlich dann die fremden Libs niemals anzupassen.

Grüße,
Garvin

Hallo Garvin.

den Composer führst du nur aus, wenn du neue Libs nutzen willst. Am Besten du liest dir mal die Doku unter getcomposer.org durch. Unter https://github.com/fadoe/Serendipity/tree/2.0 gibt es die Composer-Version mit aktuellem stand aus S9y 2.0. Nur die Anleitung funktioniert noch nicht.

Die composer.lock enthält übrigens die Paketdaten ohne require-dev. Und der UnitTest läuft auch, das dürfte der Erste für S9y sein .

Wenn du die Github-Klick-Methode nutzen willst, hindert dich keiner dran die Sourcen in einem eigenen Branch zu commiten. Ich finde diese Methode zwar nicht gerade schön, aber wenn du Otto Normalbürger S9y zum Herunterladen von Github anbieten willst ...

Viele Grüße,

Falk

falk wrote:Ich finde diese Methode zwar nicht gerade schön, aber wenn du Otto Normalbürger S9y zum Herunterladen von Github anbieten willst ...

Es ist ja nicht so, dass man irgendjemanden davon abhalten könnte, jetzt wo GitHub endlich wieder zip und tar.gz automagisch generiert.

YL

Wir (falk, onli, mattsches) haben in einem Etherpad versucht, Vor- und Nachteile des Einsatzes von Composer zu sammeln. Ich versuche, die Resultate hier in aller Kürze zusammenzufassen:

Vorteile:

• Externe Bibliotheken müssen nicht mehr innerhalb von S9y gepflegt werden. Der S9y-Core bleibt kleiner, Libs können leicht aktualisiert werden.
• Composer übernimmt das Autoloading, keine "require_once-Orgien" mehr. Ggf. Beschleunigung beim Laden von Klassen durch classmaps, vgl. getcomposer.org/doc/04-schema.md#classmap
• Evtl. später Plugin-Installation auch über Composer mit automatischem Handling weiterer externer Libs

Nachteile:

• S9y kann nicht als Archiv inklusive der externen Libs von Github heruntergeladen werden. (evtl. lassen sich diese Libs beim erstellen eines Releases help.github.com/articles/creating-releases hinzufügen?)
• Nach dem Auschecken von S9y (git clone) muss zusätzlich ein Composer Befehl (`composer install`) ausgeführt werden (evtl. lässt sich das via Post-Pull-Hook lösen, vgl. dazu https://github.com/composer/composer/pull/1083), (evtl. lässt sich das auch dem S9y-Installer beibringen (oder ist der bereits auf externe Libs angewiesen?))
• Composer requires PHP 5.3.2+ to run

Mittlerweile ist die Diskussion hier im Thread ja schon etwas weiter, da möchte ich auch noch etwas dazu sagen

Für komplette ZIP-Archive aus Github (s.o.) weiß ich keine Lösung, falls das mit den Releases nicht geht. IMHO ist Github aber die Plattform für (uns) Entwickler, und wir wissen Composer zu bedienen bzw. lernen es in wenigen Minuten.1,2 Alle anderen sollten (Pre-)Releases von s9y.org herunterladen.

Externe Libs sollten wir sowieso gar nie und nicht anpassen. Und genau das erzwingen wir auch durch die Nutzung von Composer.

Auch andere OSS-Projekte hatten diese Diskussion, z.B. Drupal. In deren Fall war u.a. der Umstieg auf Symfony2-Komponenten ausschlaggebend für die Einführung von Composer, wenn ich das richtig sehe. Vielleicht lassen sich noch Diskussionen von anderen Projekten nachlesen.

Ich halte die Diskussion hier über dieses Thema für wichtig, denn wir müssen zu einer Lösung kommen, die wir alle tragen können. Ich halte es ebenfalls für richtig, dass Entwickler wie falk vorpreschen und bestimmte Features testhalber implementieren (wir können sie ggf. später einfach per Pull Request reinziehen). Es gibt vielleicht noch nicht für alles Lösungen, aber daran können wir arbeiten. Ich habe falks Fork noch nicht ausgecheckt und getestet, habe das aber weit oben auf meiner ToDo-Liste.

1 zumindest die Befehle, die wir zum Entwickeln brauchen; das funktioniert dann übrigens auch mit den ZIP-Archiven, denn auch diese enthalten die `composer.lock`-Datei.
2 Wer `git pull` in seinem Cronjob stehen hat, muss diesem einfach noch ein `composer install` oder einen entsprechenden Hook (s.o.) hinzufügen.

Hi!

Was spricht dagegen es wie weiter oben angesprochen zu implementieren? Also die von composer per shell gezogenen libs ins git repository zu committen, damit auch alles so runterladbar ist? Mir wäre das sehr wichtig.

Grüße,
Garivn

Bei phpbb3.1 ist das wohl ähnlich mit Composer fürs developen: https://wiki.phpbb.com/PhpBB3.1

garvinhicking wrote:Was spricht dagegen es wie weiter oben angesprochen zu implementieren? Also die von composer per shell gezogenen libs ins git repository zu committen, damit auch alles so runterladbar ist? Mir wäre das sehr wichtig.

Dem schließe ich mich an! (Und das ist etwas anderes als ein täglich erzeugtes dev zip.)
Aber - dann verkommt die zugrundeliegende composer Idee zu einem "Syncronizer" und kann daher auch gleich gelassen werden. Letzteres ist mir persönlich immer noch sehr sympathisch, weil Menschen sich mit einem simplen check/copy/paste um die reale Einbindung von externen Libs kümmern - und sie müssen dabei an Garvin vorbei, der zurecht die Kompatibilitätsfahne hochhält, bis man ihn überzeugt. Jedenfalls mache ich dies mit Smarty so und kann für mich behaupten, dass Zeit oder Kompliziertheit diesbezüglich keine Argumente sind.

So viele Libs haben wir gar nicht, dass wir den composer daher dringend bräuchten. Außer, wenn man das Konzept wechseln will! (zb weil man ständig damit arbeitet und sich Serendipity hartnäckig unbeugsam dagegenstellt, wo man doch ansonsten viel schneller wäre, oder so... oder sich zukünftige Vorstellungen Einzelner leichter realisieren lassen, da man ja diese Hürde schon einmal durchgesetzt hat...) Und wie man sieht, kommt man da leicht auf eher "vertrauensbasierte" Argumentationen..., die aber immer mit ausschlaggebenden "technischen Vorteilen" begründet werden.
Ja, Symfony ist dann oft das Körnlein auf der Waagschale für den Umstieg. Wo aber ist das für S9y relevant?

Bleibt als Argument, als "Stil" und "Erziehungsmittel" für Developer, dass man externe Libs ja nie anfassen darf. Das halte ich für "argumentativen Zierrat"... Wer macht denn das ständig, dass es wirklich nötig wäre dies codeseitig zu unterbinden? ... Und manchmal gibt es für einen Patch sogar gute Gründe!

Ginge es um classmaps und autoloader vs includes..., könnte man das IMO auch so realisieren... Insofern sind die genannten "Vorteile" alles nur konzeptuale Argumente, die mich noch nicht überzeugen, dem "Hip u. Mainstream" den Vorzug gegenüber "Bewährt u. Handarbeit" zu geben.

ICE wrote:Bei phpbb3.1 ist das wohl ähnlich mit Composer fürs developen: https://wiki.phpbb.com/PhpBB3.1

Bei phpBB liegen auch nur die composer.json und die composer.lock im Repo, wenn ich das richtig sehe. Zusätzlich liefern die aber die composer.phar mit aus - halte ich jetzt auch nicht für so optimal.

@mattsches: Das die composer.phar mit im repo landet ist ein blöder Überbleibsel aus den ZF2-Anfängen. Es gibt kein Grund das zu machen. Bei liegt die phar in einem globalen bin-Verzeichnis.

@timbalu: Hier geht es nicht um neue hype Sachen, es geht um Vereinfachung und Spaß am Programmieren. (Die Softwareentwicklung ist in den letzten 10 Jahren nicht stehen geblieben!) Mich hat der Quelltext von s9y sehr lange davon abgehalten, überhaupt nur eine Zeile Code zu ändern. Nachdem ich nun die ersten Verbesserungen eingebaut habe finde ich immer wieder Stellen die ich verbessern möchte. Alter Code fliegt raus. Nach und nach soll man merken, das Serendipity kein Script-Kiddy-Projekt, sondern von Programmierern geschriebene Software ist. Wenn du davon nicht überzeugt bist, kein Problem. Ich habe für meine Änderungen noch keinen Pullrequest gestellt. Es ist keine Pflicht meine Ideen zu übernehmen, aber ich denke schon das Serendipity ein bisschen mit der Zeit gehen sollte.

@garvin: Mir gefällt es nicht externe Libs in ein Repo mit eigenen Sourcen zu laden. Für solche Zwecke gibt es mehrere Repos und Composer als Hilfsmittel. Wenn du der Meinung bist dies machen zu wollen dann bitte. Ich schaue mir die Tage mal die Lösungen der anderen Projekte an. Aber wie Onli schon sagte: Entwickler ziehen sich die Sourcen von Gitbhub. Und die sollten nun mal wissen wie man eine Online-Doku liest und ein Programm ausführt.

So, meine 5 Cent für heute.

falk wrote: (Die Softwareentwicklung ist in den letzten 10 Jahren nicht stehen geblieben!)
Nach und nach soll man merken, das Serendipity kein Script-Kiddy-Projekt, sondern von Programmierern geschriebene Software ist.

Vielleicht, lieber Falk, ist es auch nur diese Überheblichkeit, die mich hier zum Advokatus Diavoli werden lässt. Es ist genau das, was ich die ganze Zeit daran bemängelt habe: Das Motiv und Argumentation nicht übereinstimmen. Mit der Ausssage das Serendipity vor 10 Jahren stehengeblieben und ein Produkt von Skript Kiddies sei und jetzt erst mit deinen Änderungen ... [].
Kurz gesagt, damit diskreditierst du dich! Aber ich danke für die klare Aussage. Sie macht es mir deutlich einfacher klar Position zu beziehen.

falk wrote:..das Serendipity ein bisschen mit der Zeit gehen sollte.

Ist eben nur da sinnvoll, wo es Sinn macht. Mit neuen Techniken allein ist es nicht getan. Ich finde es gut, den Schwung in 2.0 nicht nur für ein neues Backend Template zu nutzen, sondern auch etwas aufzuräumen, bestimmte Teile zu überdenken, völlig Altes neu zu setzen, etc. Ich wünschte, dies ließe sich in einem gemeinsamen Geiste bewerkstelligen.