Composer 1 zu Composer 2

Composer ist "nur" ein Commandline PHP Programm, das als ein eigenständiges File (im phar format) aufgerufen wird. Das ist also keine Server-Software, die man irgendwie von einem Hoster installiert bekommen muss. Man kann sich also generell sowohl eine composer1(.phar) und ein composer2(.phar) herunter laden und betreiben. Man kann diese sogar mit unterschiedlichen PHP Versionen laden. Somit kann man auf dem gleichen System mit dem gleichen System-Benutzer sowohl composer 1 parallel mit composer 2 nutzen. Wenn man das täglich benötigt ist es natürlich hilfreich, wenn man irgendwie vereinfach hat mit dem Aufruf. Wenn z.B. die Commandline auch das bin Verzeichnis im Home Verzeichnis auslesen kann, kann man da z.B. die paar Daten direkt einspeichern und umbenennen in composer1 und composer2 oder alias/symlinks anlegen. Wenn diese in der commandline nicht direkt als ausführbare Dateien interpretiert werden (z.B. via bash Konfiguration) kann man dann trotzdem einfacher aufrufen z.B. mit "~/bin/composer1". So mache ich das z.B. auf meinem Laptop und bei Hosting-Plattformen, die wir nicht selbst komplett verwalten.
Wichtig bei Composer Operationen auf unterschiedlichen Umgebungen (wie z.B. lokale Nutzung): Im Composer.json die Ziel PHP Version festlegen und beim Update mit der gleichen PHP Version oder einer höheren aufrufen. Dann sorgt Composer dafür, daß man nicht aus Versehen Paket-Versionen installiert, die z.B. PHP 8.2 schon benötigen obwohl auf dem Ziel-System 8.1 genutzt wird.
Aber selbst wenn man alles auf dem Ziel-Server ausführt, kann es sein, daß die Commandline nicht die gleich PHP Version verwendet wie der Webserver. Mit "php -v" findet man das raus. Wenn lokal und Servern unterschiedliche PHP Version verfügbar sind, kann man sich dafür auch Symlinks/aliase anlegen.

Es generell ist es ratsam für Composer Update (Massnahmen) z.B. bei einem Drupal Projekt, dies nicht direkt auf dem Produktiv Server durchzuführen, sondern z.B. Lokal und das "Ergebnis" (insbesondere die composer.lock Datei) dann hoffentlich via Git und mindestens einem Staging Test erst zum produktiv-System zu transferieren und dort dann composer install durchzuführen. Mit Composer 2 ist zwar der Speicherhunger von Composer erheblich besser geworden bei Updates aber es ist trotzdem ein gute Idee. Bei Projekten, bei denen wir (nicht mehr) den ganzen Code im Git-Repo verwalten (wollen) gehen wir aktuell dazu über, den Composer-Prozess (auch nicht install) nicht mehr direkt im Produktiv-Code Ordner durchzuführen, da beim Install Dateien aus unterschiedlichen Quellen herunter geladen werden. Selbst wenn man diese mit einem Mirror (z.B. bei Packagist.com, kostenpflichtig) absichert, kann es sein, daß das Ergebnis unvollständig ist bzw. der Install-Prozess sich zu sehr hinzieht und z.B. ein Patch nicht geladen wird usw. Wir machen dann ein Abgleich mit Rsync (bzw. haben dafür ein Script).

Deine Antwort gehört ins "how to compose with composer"Handbuch - vielen Dank. Ich bin da ein Einsteiger - ein Profi hat für mich ein bash script erstellt, ich werd mir das abschauen und für composer 2 adaptieren.

Das mit den unterschiedlichen PHP Versionen hat mich auch schon verwirrt und ist als Frage im Forum abgehandelt worden, wichtige Info!

Deine beschriebene Vorgangsweise mit lokale Version...via Git...etc. habe ich erst einmal in den Anfängen versucht, da hatte mir "sammelzwerg" eine gute Anleitung gegeben, und ich war mit den shell Befehlen bzw. dem Grundverständnis noch nicht so weit. Kommt auch.

Mein bash script sieht wie folgt aus - und da ist die Frage, wo ich composer 2 "beauftragen" kann - oder ist die composer Version in einem weiteren script angeführt?

Das Bash Script kann man so machen, es ist für meinem Geschmack allerdings zu unflexibel. Wir haben da intern eine Script-Sammlung, die sich sogar in sehr unterschiedlichen Hosting-Umgebungen nutzen lässt durch Konfigurations-Dateien und dem Auslesen von Meta-Daten etc.

Mit ist aber aufgefallen, daß ich folgende Frage noch nicht wirklich beantwortet habe weil ich (auch aus Gewohnheit) von unterschiedlichen Projekten ausgehe, da wir immer mehr als eines z. B. lokal betreuen und Drupal 7 noch mit Composer 1 und Drupal 9 Projekte bereits alle mit Composer 2 pflegen und wir deshalb lokal und auf Servern beide Composer Versionen benötigen:

> Ein Composer update ist mir klar, aber was passiert mit den Projekten, die noch mit Composer 1 aufgesetzt wurden?

Wenn es darum geht, ein Projekt, daß mit Composer 1 aufgesetzt wurde und dann mit Composer 2 weiter gepflegt werden soll. Wenn es gut läuft, ist ein fliegender Wechsel möglich. Das kann klappen, wenn man noch mit Composer 1 alle Bibliotheken (d.h. nicht nur Drupal Module) auf den neuesten Stand gebracht hat. Denn auch die Composer Packages müssen Composer 2 API kompatibel sein. Da "nörgelt" Composer 2 aber beim Upgrade und dann kann man sich auf die Suche begeben, welche Bibliothek da noch "quer" steht. Das sind inzwischen seltener Bibliotheken, die vom Core oder gut gepflegten Modulen als Requirement angegeben werden sondern oft eher jene, die man manuell hinzugefügt hat aus ganz unterschiedlichen Gründen und diese irgendwann mal begrenzt hat in der Versions-Angabe usw. Da muss man sich dann ran testen und zur Not sich auch mal von etwas trennen bzw. es anders organisieren und zur Not Patches arbeiten. Da gibt es jetzt keine pauschale Anleitung für.

Ich hab bei meinen beiden Drupal 9.5.2 Projekten von Anfang an mit composer gearbeitet und den Betrieb immer mit c. aktuell gehalten. Händisch hinzugefügt habe ich soweit erinnerlich nichts. Das ganze im Hinblick auf die Vorbereitung auf Drupal 10. Module habe ich nicht so viele in Verwendung und werde es so halten, dass ich auf das eine oder andere verzichte, wenn es zwickt.

Hab jetzt am Wochenende wieder mit composer "geübt" - den composer in anderer suobdomain frisch installiert, dann diese Version 1.x sogar auf 2.x upgedated - da murrte er erst herum, keine .json Datei zu haben, also hab ich eine "gebastelt". Dann den Versuch wieder abgebrochen. Zudem schien es so, wie wenn der andere "alte" bereits installierte composer gleich mitgeupdated worden wäre. Bei der Versionskontrolle zeigte er es so an. Da ist mir noch einiges unklar.

So wie ich es verstanden habe ist der composer wenn dann sinnvollerweise für alles im root zuständig, global verfügbar. Kann ich aber dennoch in einem Unterverzeichnis eine andere composer Version betreiben? Da muß die composer.phar eben dort liegen und dort auch angesprochen werden. Stimmt die Annahme? Und so ein bash script würde mir die Mühe abnehmen, dass ich immer wieder Pfade eingebe - siehe obiges Beispiel, das hatte mir ein Profi gebaut - für Kurzbefehle.

Wo ich noch völlig im Dunklen tappe ist: In den diversen tutorials ist immer die Rede von dem Ordner /bin, dann auch von der bash - darüber sind die Infos bunt verstreut - wahrscheinlich weil jeder annimmt, dass es Grundlagenwissen sei.
Was tun, wenn man(n) nicht in der IT-Branche aufgewachsen sondern enthusiasmierter Laie ist? Na im Forum fragen.