wsl mit ddev lokale repos in der composer.yaml referenzieren?

Hallo in die Runde,

ich bitte hier die erfahreren ddev-unter-wsl Entwickler erneut um etwas Hilfe oder Tipps...

Aktuell bin ich bei der Übertragung meiner bisherigen Projekte von Laragon nach WSL + ddev etwas weiter gekommen, aber der Prozess ist wirklich holprig und birgt einige Klippen...

Nachdem ich ein Standardprojekt gemäß Conto-Docs aufgesetzt habe, was in meiner Konfiguration nur unter ganz bestimmten Randbedingungen funktioniert (was hier nicht das Problem sein soll), bin ich jetzt an dem Punkt angekommen, dass die Test-Installation von C5.4 funktioniert. Ich habe danach meine lokalen Repos vom NAS wieder auf meine Entwickler-Maschine gezogen und möchte jetzt ein ddev composer update unter Nutzung der lokalen Repos ausführen.

Das schlägt fehl, weil die Pfade/URLs nicht stimmen. Das war erwartbar und sollte kein Problem sein. Vorsichtshalber habe ich die Repos in das wsl-Filesystem kopiert, um von vornherein sog. cross filesystem boundary errors zwischen Windows und wsl zu vermeinden.

Mein Test-Projekt befindet sich in /dev/contao/test-projekt

Alle Repos befinden sich in /dev/PHPStormProjects.

Die composer.yaml enthält folgende Referenzen

Code:

"repositories": [ { "type": "path", "url": "~/phpstormprojects/contao-pge-bundle" egal ich hab auch "url": "~/PHPStormProjects/contao-pge-bundle" probiert }, { "type": "path", "url": "~/PHPStormProjects/php-gedcom" }, { "type": "path", "url": "~/PhpStormProjects/contao-supervisor-bundle" }, { "type": "path", "url": "~/PhpStormProjects/contao-backref-bundle" } ],

Jedoch kennt der composer den angegebenen Pfad nicht. Das liegt wohl daran - und hier bitte ich um Hinweise - dass er außerhalb seines laufenden docker-containers (/dev/contao/test-projekt) nicht zugreifen kann.

Nun besteht wohl die Möglichkeit, Repositories außerhalb des docker containers zu mounten. Dazu bin ich wie hier erklärt verfahren.

Ich habe also eine Datei namens .ddev/docker-compose.mounts.yaml angelegt und in meinem Projekt-ddev-Verzeichnis (/dev/contao/test-projekt/.ddev) platziert. Das hat keine Auswirkung!
Ich habe die Datei dann nochmals im user ddev-Verzeichnis (User dev -> /dev/.ddev) platziert, was aber ebenso keine Auswirkung hat.

Code:

services: web: volumes: - "$HOME/PHPStormProjects:/home/phpstormprojects" oder auch - "$HOME/PHPStormProjects:~/phpstormprojects"

Nach jeder Änderung habe ich ddev stop & start ausgeführt. ddev composer Update findet nach wie vor den Repo-Pfad nicht.

Was müsste ich tun, damit ddev composer update die Repos findet?

Vielleicht kann jmd. helfen, der sein Windows-System mit wsl bereits zum Laufen bekommen hat?

Vielen Dank und beste Grüße
Theo

gibts wirklich niemand, der Erfahrung mit diesem Setting hat?? :eek:

OK. Hier die Lösung!

Wenn man eine Contao-Instanz unter WSL2 mit ddev und composer in Betrieb nehmen möchte, so ist das erst einmal gemäß dieser Anleitung https://docs.contao.org/manual/de/an...allation/ddev/ grundlegend möglich.

Das funktioniert für eine leere Installation (in meinem Falle Contao 5.4.6) gut.

In der Regel verwendet man jedoch bei der Entwicklung von Bundles ein lokales Git-Repository und bindet die in Entwicklung befindlichen Bundles von dort via composer.yaml mit dem key "repositories" ein.

In der Grundinstallation auf einer neuen Maschine schlägt das erst einmal fehl, weil der docker-container keinen Bezug zum Repository hat. Das ist soweit auch verständlich.

Außerdem hat man manchmal die Anforderung, zwei Contao-Instanzen für die Entwicklung von Client-Server-Szenarien parallel zu betreiben, wobei sich beide Instanzen die gleichen Repos teilen müssen.

Jedoch blieb bei mir die Frage, wie man diesen Bezug herstellen kann. Das ist leider in der o.g. Doku nicht erklärt und dort fängt die professionelle Arbeit an. Also:

Um einen Bezug zum Repository herzustellen, ist es nötig das Repo mit seinen Dateien im Linux-System (bei mir WSL2 Ubuntu 24.04) bereitzustellen. Dazu gibt es verschiedene Verfahren. Ich habe das Verfahren des "Einbindens eines Host-Pfades in den docker-Container" gewählt (man kann auch ganze Volumes mounten oder auf einen anderen Server via Netzwerk zugreifen).
Hier liegt das Augenmerk auf "Host-Pfad" (der Host ist hier WSL2), denn es ist auch möglich das Git-Repo im Windows-Filesystem abzulegen. Leider muss man dabei mit Schwierigkeiten (Pfad ist nicht erreichbar, falsche Benutzerrechte) oder geringer Performance rechnen. Daher finden sich in den verschiedenen Dokumentationen die Hinweise, keine cross-border-filesystem Zugriffe zu provozieren (also Zugriffe aus dem Linux-Filesystem in das Windows-Filesystem und umgekehrt). Daher sollte das Repo gleich in das Linux-Filesystem übertragen werden.
Das Kopieren des Repos in das Linux-Filesystem sollte kein Problem sein, da WSL2 den dirketen Zugriff via Windows-Explorer zulässt. Auch habe ich ein direktes Git-Checkout unter Ubuntu ausgeführt. Das Ergebnis ist dasselbe.
Empfohlen wird auch, das Repo in einen Pfad unterhalb des aktuellen Users abzulegen. Mein User heißt dev und sein Directory befindet sich standardmäßig in /home/dev. Dort habe ich einen Ordner repository angelegt.
Währen meine ddev-Instanzen unter /home/dev/contao abgelegt sind, befinden sich alle in Entwicklung befindlichen Bundles in /home/dev/repository.
startet man nun den container mit ddev start und führt dann ein ddev composer update aus (Achtung, composer muss im neueren ddev - bei mir 1.23.5 - nicht mehr gesondert installiert werden, er ist jetzt über den Befehl ddev composer erreichbar), so erhält man wahrscheinlich einen composer-Fehler wie The `url` supplied for the path (/my/missing/repository/contao-my-bundle) repository does not exist., da composer die urls der Repos nicht auflösen kann.
Um diesen Umstand zu beheben, muss man das Repo nun in den Docker-Container einbinden. Das geschieht wie folgt:
a.) man sucht die für die Contao-Instanz zuständige ddev-Instanz. Diese befindet sich normalerweise im Contao-Projektpfad im Ordner .ddev, also bei mir unter /home/dev/contao/meine-contao-instanz-01/.ddev
b.) dort legt man nun eine neue docker-compose-datei an. Man beachte dazu diese Hinweise. Die Datei muss der Namenskonvention folgen und wird beim ddev start automatisch geladen.
c.) die Datei muss dem Schema docker-compose.*.yaml folgen, also sie kann beispielsweise docker-compose.bundle-repository.yaml heißen (siehe ausführlich dazu unter dem Link Hinweise).
d.) in diese Datei muss folgende (prinzipielle) Konfiguration eingetragen werden:

Code:

version: '3' services: web: volumes: - /path/to/host/repo:/path/inside/docker/container

Hinweis: Bei neueren ddev-Installationen kann "version" entfallen. Man erhält eine Warnung beim Start des Containers mit dem Hinweis, diesen Schlüssel zu entfernen.
Hinweis: Ich habe an verschiedenen Stellen gelesen, dass die Pfade absolut sein müssen und Docker hier keine relativen Pfade akzeptiert. Überprüft habe ich das aber noch nicht.
Die konkrete Datei sieht in meinem Fall so aus:

Code:

services: web: volumes: - /home/$USER/repository:/home/$USER/repository:rw

docker-compose unterstützt einige Variablen, wie hier $USER. Siehe dazu mehr hier.
e.) dann führt man im Projektverzeichnes (also hier /home/dev/contao/meine-contao-instanz-01) ein ddev restart aus.
Wenn unter Windows 11 ddev korrekt installiert wurde, so sollte mkcert bereits installiert sein. Daher kann man jetzt mit ddev ssh überprüfen, ob das Directory korrekt in den Container eingebunden wurde. Man startet ddev ssh und führt ein ls auf den neu eingebundenen Pfad aus, also: ls -l /home/$USER/repository (bei mir konkret mit $USER = dev). ls sollte jetzt alle bundles im Repo auflisten.
bitte jetzt nochmal die composer.yaml des Projekts überprüfen. Dort sollte in allen urls folgendes (o.ä.) stehen:

Code:

"repositories": [ { "type": "path", "url": "~/repository/contao-01-bundle" }, ... ]

Hinweis: Wer wenig Erfahrung mit Linux hat, ~ wird zu /home/dev expandiert, also es entsteht wieder /home/dev/respository/contao-01-bundle.
Wenn das erfolgreich war, kann man die referenzierten Bundles im Repo in allen weiteren Contao-Instanzen nutzen. Dazu kopiert man lediglich die docker-compose.bundle-repository.yaml in alle Instanzen und zwar in die jeweiligen Ordner /.ddev.
Prinzipiell kan man die Repos auch in allen Docker-Containern auf dem System bereitstellen, indem man sie gleich in das Docker-Base-Config aufnimmt, aber das habe noch nicht getestet.

Ich hoffe, es nützt Euch?!

Zum Schluss möchte ich noch erwähnen, dass dieses Setting (ohne weiteres Tunen) bei mir auf einem neuen Win11x64Prof Ryzen 9 9950X ca. 10x schneller antwortet als meine frühere Laragon-Umgebung. Es lohnt sich also umzusteigen...

Beste Grüße vom
Theo