Arbeit mit dem Composer Client im Team per Git

[The_Unknown]

Hallo,

wir haben seit ca. 2 Wochen den neuen Composer Client im Entwicklungseinsatz. Dabei gibt es ein paar Probleme mit dem Workflow (evtl. arbeiten wir auch einfach nach einem für Composer Client ungünstigen Workflow):

1. Es gibt Probleme mit unseren eigenen Submodulen. Ein "git submodule foreach git pull" ist ohne Weiteres nicht mehr möglich, da manche Contao-Erweiterungen über Composer als git-Submodul geholt werden. Der genannte git-Aufruf versucht dann bspw. multicolumnwizard auszuchecken, was fehlschlägt, weil kein Eintrag in der .gitmodules gefunden wurde. Wir haben daher ein Skript geschrieben, was nur die Erweiterungen aus dieser Datei updatet. Für uns so ok. Aber gibt es hier evlt. eine bessere Lösung?
2. Erweiterungen, die als Submodul geladen werden (bspw. multicolumnwizard), d.h. keine Legacy-Module, werden "nur" als git-Referenz eingecheckt. Wenn sich ein neues Teammitglied das Projekt neu klont, sind die Ordner in composer und auch in system/modules leer, was zu Fehlern führt. Manchmal sind auch leere Ordner darin, die man erst löschen muss, damit die Erweiterung über Composer neu installiert werden kann. Was könnte man hier tun?
3. Die Dateistruktur erschließt sich mir noch nicht so ganz. Warum müssen die Erweiterungen in system/modules und auch in composer/vendor vorhanden sein? Reicht nicht ersterer Ort?

Vielen Dank im Voraus!

Ciao The_Unknown

[webstar]

Hallo,

wir haben seit ca. 2 Wochen den neuen Composer Client im Entwicklungseinsatz. Dabei gibt es ein paar Probleme mit dem Workflow (evtl. arbeiten wir auch einfach nach einem für Composer Client ungünstigen Workflow):

1. Es gibt Probleme mit unseren eigenen Submodulen. Ein "git submodule foreach git pull" ist ohne Weiteres nicht mehr möglich, da manche Contao-Erweiterungen über Composer als git-Submodul geholt werden. Der genannte git-Aufruf versucht dann bspw. multicolumnwizard auszuchecken, was fehlschlägt, weil kein Eintrag in der .gitmodules gefunden wurde. Wir haben daher ein Skript geschrieben, was nur die Erweiterungen aus dieser Datei updatet. Für uns so ok. Aber gibt es hier evlt. eine bessere Lösung?

Wenn ich es richtig verstehe, habt ihr das gesamte Projekt (inkl. Contao) in einem Git und entwickelt darin auch eure Erweiterungen, richtig? Ich halte dies eigentlich immer strikt getrennt. Alle projektspezifischen Dateien (Theme, ggf. Erweiterungen), die zu einem Kundenprojekt gehören kommen in ein Git/mehrere Gits je nach Projekt und werden dann in eine bestehende Installation integriert. Über die Repository-Konfiguration des Composers (https://getcomposer.org/doc/05-repositories.md#vcs) werden auch einfach lokale Repositories zu laden.

Desweiteren arbeite ich nicht mit Submodulen, sondern lade mir über Composer die abhängigen Erweiterungen. Dies funktioniert auch in einer Erweiterung. Dazu packe ich den vendor Ordner einfach ins gitignore.

1. Erweiterungen, die als Submodul geladen werden (bspw. multicolumnwizard), d.h. keine Legacy-Module, werden "nur" als git-Referenz eingecheckt. Wenn sich ein neues Teammitglied das Projekt neu klont, sind die Ordner in composer und auch in system/modules leer, was zu Fehlern führt. Manchmal sind auch leere Ordner darin, die man erst löschen muss, damit die Erweiterung über Composer neu installiert werden kann. Was könnte man hier tun?

Ich würde versuchen alle Ordner, die nicht benötigt werden per gitingore auszuschließen, sodass sie nicht im Git sind. Geht wohl nur, wenn man auf den submodule Ansatz verzichtet.

1. Die Dateistruktur erschließt sich mir noch nicht so ganz. Warum müssen die Erweiterungen in system/modules und auch in composer/vendor vorhanden sein? Reicht nicht ersterer Ort?

Dies ist darauf geschuldet, dass Contao eine feste Struktur vorgibt (alle Module müssen unter system/modules liegen). Dies lässt sich jedoch nicht mit Composer abbilden. Daher kopiert die Composer-Integration von Contao die dafür vorgesehenen Dateien aus dem Vendor Verzeichnis auch unter system/modules.

[The_Unknown]

Wenn ich es richtig verstehe, habt ihr das gesamte Projekt (inkl. Contao) in einem Git und entwickelt darin auch eure Erweiterungen, richtig? Ich halte dies eigentlich immer strikt getrennt. Alle projektspezifischen Dateien (Theme, ggf. Erweiterungen), die zu einem Kundenprojekt gehören kommen in ein Git/mehrere Gits je nach Projekt und werden dann in eine bestehende Installation integriert. Über die Repository-Konfiguration des Composers (https://getcomposer.org/doc/05-repositories.md#vcs) werden auch einfach lokale Repositories zu laden.

Desweiteren arbeite ich nicht mit Submodulen, sondern lade mir über Composer die abhängigen Erweiterungen. Dies funktioniert auch in einer Erweiterung. Dazu packe ich den vendor Ordner einfach ins gitignore.

Noch mal Edit: Das ganze funktioniert nun (die Submodule sind nun als Composer-Erweiterungen eingebunden, wie du es geschrieben hattest; der vendor-Ordner ist auf dem Index). Leider gibt es auf den Macs noch Probleme beim Auschecken. Wenn ich auf einem Mac, der eine neue Erweiterung noch nicht hat, auf "Pakete aktualisieren" klicke, bekomme ich folgenden Fehler

Failed to clone ssh://git@git.dd.net.hhsp.de/contao/xcommon.git, git was not found, check that it is installed and in your PATH env. sh: git: command not found

Ich kann das Modul aber an Ort und Stelle mit "git clone ..." auschecken. Auch vom Terminal aus ist git problemlos erreichbar. Was läuft hier falsch?

[xtra]

Git ist nicht im environment ($PATH) deines PHP prozesses auffindbar. Daher meckert er es an.

[The_Unknown]

Wenn ich es richtig verstehe, habt ihr das gesamte Projekt (inkl. Contao) in einem Git und entwickelt darin auch eure Erweiterungen, richtig? Ich halte dies eigentlich immer strikt getrennt. Alle projektspezifischen Dateien (Theme, ggf. Erweiterungen), die zu einem Kundenprojekt gehören kommen in ein Git/mehrere Gits je nach Projekt und werden dann in eine bestehende Installation integriert. Über die Repository-Konfiguration des Composers (https://getcomposer.org/doc/05-repositories.md#vcs) werden auch einfach lokale Repositories zu laden.

Aber einige Submodule brauchen ja den Kontext eines Projekts. Wie entwickelst du dann diese Submodule weiter, ohne bei *jedem* Test im Projekt updaten zu müssen? Ich nehme an, du bearbeitest das Submodul dann in seinem eigenen Repo an einer separaten Stelle.

[tril]

Du arbeitest einfach gar nicht mit Submodulen. Submodule werden von Composer nicht unterstützt. Ich mach für mein Website Projekt mittlerweile einfach ein Composer Paket für die ganzen Projektspezifischen Web-Daten (Layout, Bilder, Scripts, etc.).
Gleiches würde ich mit euren ganzen submodulen machen und diese einfach in Composer Pakete "umwandeln", dafür brauchst du ja lediglich eine composer.json anlegen. Dann kannste alle Erweiterungen, die du jetzt "aufwändig" als submodule verwaltest dann einfach via Composer verwalten kannst

[The_Unknown]

Vielleicht hätte ich nicht "Submodule" sagen sollen, denn die git-Submodule meinte ich nicht. Mittlerweile sind es Composerpakete, aber o.g. Frage bzw das Problem bleibt trotzdem bestehen.

[webstar]

Aber einige Submodule brauchen ja den Kontext eines Projekts. Wie entwickelst du dann diese Submodule weiter, ohne bei *jedem* Test im Projekt updaten zu müssen? Ich nehme an, du bearbeitest das Submodul dann in seinem eigenen Repo an einer separaten Stelle.

Wenn ich einzelne Module habe, dann müssen diese auch separat funktionieren bzw. die entsprechenden Abhängigkeiten definieren. Wenn es losgelöst weiterentwickelt vom eigentlichen Projekt getestet werden soll, dann muss es halt in der lokalen Testumgebung des Entwicklers getestet werden. Wenn sich durch die Änderungen auch Änderungen am Hauptprojekt ergeben, so werden auch im Hauptprojekt die Änderungen vorgenommen.

Beantwortet das deine Frage? Ich verstehe noch nicht ganz, wo es hängt.

[The_Unknown]

Die Situation:

- 1 Projekt
- 1 git-Submodul als Composerpaket eingebunden (das git-Repo des git-Submoduls, welches als Composer-Paket eingebunden ist, ist in der repositories-Sektion eingetragen)

Soweit so gut, nun möchte ich dieses git-Submodul aber weiterentwickeln. Es braucht dafür den Kontext eines Projekts. Dann gibt es jetzt 2 Möglichkeiten, o man die Änderungen einbaut. Die "saubere" Lösung wäre, die Änderungen im Submodul-Repo zu machen, zu pushen und dann mit dem Composer wieder zu aktualisieren. Dadurch brauche ich aber ewig, wenn ich jeden Schritt erst mühselig auschecken muss. Möglichkeit 2 wäre, in das Modul direkt im konkreten Projekt zu coden. Wenn ich dann nun aber zum Committen dieser Änderungen in das Verzeichnis gehe und dort git push ausführe, damit alles ins git-Submodul-Repo geht, kommt es beim Aktualisieren des Composers zu Exceptions.

Ich hoffe, man versteht es nun

[tril]

Ich denke, The_Unknown's Problem ist dass die ganzen Dateien aus TL_ROOT/composer/vendor/... in die entsprechenden Bereiche nach system/modules/... etc. "kopiert" werden?
Du musst die "Bevorzugte Installationsart" auf "Quellen" umstellen (siehe Einstellungen in der Paketverwaltung). Dann werden die Dateien gesymlinkt, anstatt sie zu kopieren. Dann kannste nach belieben entwickeln ohne nach jeder Änderung einen Commit und ein Update machen zu müssen.

[The_Unknown]

Daran hatte ich auch schon gedacht, aber dadurch werden doch auch die anderen Pakete standardmäßig mit git heruntergeladen, oder?

[tril]

Möglichkeit 2 wäre, in das Modul direkt im konkreten Projekt zu coden.

Das mache ich NUR so

Wenn ich dann nun aber zum Committen dieser Änderungen in das Verzeichnis gehe und dort git push ausführe, damit alles ins git-Submodul-Repo geht, kommt es beim Aktualisieren des Composers zu Exceptions.

Ich hoffe, man versteht es nun

Äh, da sprichst du jetzt allerdings zum ersten mal von, was denn für eine Exception?

[tril]

Daran hatte ich auch schon gedacht, aber dadurch werden doch auch die anderen Pakete standardmäßig mit git heruntergeladen, oder?

Ja und? Ist doch egal, ich habe bei mir bei allen Installationen die Installationsart auf Quellen gestellt

[The_Unknown]

OK, das sollte ja bestimmt auch nachträglich gehen. Dann versuche ich es mal

[webstar]

Ich habe mich mit dem Entwickeln direkt im Projekt nicht wirklich anfreunden können. Mein Workflow sieht folgendermaßen aus:

• Initial das Modul über repositories aus der lokalen Quelle in Composer laden (Composers Installationsart steht auch auf Qullen)
• Programmierung außerhalb des Projektes. Um nicht jede Änderung commiten, pushen und Composer aktualiseren muss, nutze ich die Deployment Möglichkeit (PHPStorm) und überschreibe so das installierte Module in der Testumgebung

Die Vorgehensweise mit dem Deployment hatte ich bereits vor Composer. Gerade bei Installationen mit mehreren Umgebungen (lokale Entwicklunginstallation, Test-Installation sowie Liveumgebung) ist es so recht konfortabel gewesen die Änderungen zu deployen.

Durch Composer hat sich mein Workflow dahingehend geändert, dass dann das Deploying auf das Livesystem natürlich über Pakete installieren läuft.

[tril]

@webstar so ähnlich habe ich vorher auch gearbeitet, ich habe meine Repos auch in der Regel noch mal in einem lokalen workspace ausgecheckt. Ich ziehe mir dann aber oft die Repositories als Symlinks in ein Composer'ized Projekt rein, dann ist es mir egal ob ich auf der Installation oder dem workspace arbeite, manchmal sogar parallel an beidem
Das Deployment nutze ich eigentlich nur, wenn ich lokal entwickel, die Installation aber irgendwo auf dem Server liegt. Für meine Extension-Entwicklung befindet sich alles bei mir lokal, da nehme ich lieber Symlinks, das ist schneller einzurichten

[webstar]

@tril die Composer-Pakete als Symlink setzen wäre meine optimale Lösung. Wie handhabst du dabei die initiale Einrichtung? Also wie installierst du das Paket, das du als symlink einrichtest, sodass auch die Dependencies aufgelöst werden? Setzt du den Symlink vor composer update und Composer geht dann davon aus, dass bereits die aktuelle Version installiert ist?

[tril]

Wie handhabst du dabei die initiale Einrichtung? Also wie installierst du das Paket, das du als symlink einrichtest, sodass auch die Dependencies aufgelöst werden?

Ich füge das Paket erst in die composer.json hinzu, als Version wähle ich den dev-X branch den ich für die Entwicklung verwende, das ist in der Regel dev-develop. Dann lass ich das Paket es ganz normal installieren. Wichtig dabei ist, dass man auf Source Installation ist!
Anschließend gehe ich nach TL_ROOT/composer/vendor/X und lösche dort das Paket Y raus, welches ich anschließend direkt symlinke. Wenn ich Abhängigkeiten auf eigene Erweiterungen habe, mache ich das bei denen genau so.
Das ist einmalig, dafür habe ich dann die "aktuellsten" Sourcen von meinen Extensions immer direkt in meiner lokalen Installation.
Beim Update via Composer muss man ggf. ein wenig aufpassen. Composer würde zwar keine Änderungen ungefragt überschreiben, aber ggf. checkt er auf einen älteren commit aus. Da muss man ggf. lokal gelegentlich noch mal nachziehen, das passiert aber eher selten.

[webstar]

Beim Update via Composer muss man ggf. ein wenig aufpassen. Composer würde zwar keine Änderungen ungefragt überschreiben, aber ggf. checkt er auf einen älteren commit aus. Da muss man ggf. lokal gelegentlich noch mal nachziehen, das passiert aber eher selten.

Danke für die ausführliche Erklärung. Hatte ähnliches vermutet. Hab ich mal ausprobiert. Bei mir funktioniert dieses Vorgehen leider nicht, da ein Composer update mit dem gesymlinkten Paket nicht klarkommt. Ich erhalte dann folgende Exception:

[RuntimeException]                                                                                                 
  Failed to execute git remote set-url composer '/medi/...' && git fetch   
  composer && git fetch --tags composer                                                                              
  fatal: Kein solches Remote-Repository 'composer'

Installationsart steht auf Quellen, Einstellungen bei Änderungen verwerfen ist egal. Habe alles probiert. Kennst du dies und hast eventuell nen Tipp? Das einzige, was mir Google dazu ausgibt ist folgendes: https://github.com/composer/composer/issues/2202, was mir aber auch nicht weiterhilft

[tril]

Doch doch, das geht, ich habe das gleiche Problem

fatal: Kein solches Remote-Repository 'composer'

Die Meldung sagt eigentlich alles, dir fehlt das Remote "composer".
Normalerweise hast du immer das Remote "origin" in GIT, Composer arbeitet aber (aus guten Gründen) auf einem eigenen Remote, namens "composer".
Du musst also nur das Remote "composer" zum GIT Repository hinzufügen

cd /path/to/your/project
git remote add composer $url

Wobei $url natürlich die Repository URL sein muss, bspw. git@github.com/webstar/extension.git

Das musst du einmalig machen, danach läufts

[webstar]

Wenn ich so drüber nachdenke, hätte man auch selber drauf kommen können. Danke, so funktioniert's. Für manche Fälle ist das jetzt definitiv eine Erleichtung.