4.4.x Umzug/Kopie mit composer.lock

Hallo,
für eine Kopie/Umzug einer bestehende Installation wurden hier schon zahlreiche Vorgehensweisen
mit der jeweiligen composer.json beschrieben s. auch Beitrag

Ist bei einem Umzug über die composer.json dann die jeweilige php Umgebung egal - z.B. quelle php70 & ziel php71 oder umgekehrt (solange die Contao System Vorausetzungen erfüllt sind)?
Wenn ich es richtig verstanden habe würde hierbei aber auch auf mögliche neuere Paket Versionen aktualisiert.

Möchte ich nun eine 1:1 Kopie hinsichtlich der Paket Versionen haben kann man hierzu ja die entsprechende composer.lock nutzen / zusätzlich kopieren.
Wie sieht es dann mit der php Umgebung für Quelle/Ziel aus? Muß diese dann vollständig identisch sein?

Danke
Frank

Zitat:

---

Zitat von Franko

Ist bei einem Umzug über die composer.json dann die jeweilige php Umgebung egal - z.B. quelle php70 & ziel php71 oder umgekehrt (solange die Contao System Vorausetzungen erfüllt sind)?

---

Nein, ist nicht egal. Die PHP Version, die beim Erzeugen der composer.lock verwendet wurde muss die selbe sein, wie die, die vom Webserver verwendet wird. Andernfalls muss die richtige PHP Version vor dem composer update in der composer.json festgelegt werden.

Zitat:

---

Zitat von Franko

Wenn ich es richtig verstanden habe würde hierbei aber auch auf mögliche neuere Paket Versionen aktualisiert.

---

Bei einem composer install werden die Pakete so wie sie in der composer.lock definiert sind installiert. Neuere Paket Versionen, als in der composer.lock definiert sind, werden nicht installiert.

In manchen Fällen mag das gut gehen, in manchen auch nicht. Die Abhängigkeiten können je nach PHP-Version ja durchaus unterschiedlich sein. Würde ich nicht so machen.

Empfehlen würde ich die Vorgehensweise durchaus. Man muss es nur richtig machen ;)

Zitat:

---

Zitat von Spooky

Nein, ist nicht egal. Die PHP Version, die beim Erzeugen der composer.lock verwendet wurde muss die selbe sein, wie die, die vom Webserver verwendet wird. Andernfalls muss die richtige PHP Version vor dem composer update in der composer.json festgelegt werden.

---

Ok - Danke,
das gilt dann aber nur in Zusammenhang mit der composer.lock.
Wenn ich "nur" die composer.json nehme kann die php Umgebung auf dem Zielserver schon unterschiedlich sein - Oder?

Zitat:

---

Zitat von Spooky

Empfehlen würde ich die Vorgehensweise durchaus. Man muss es nur richtig machen ;)

---

Ein Schelm :-)

Wie würde das denn dann aussehen müssen?
Habe z.B. auf einer Synology Diskstation nur php70 und würde gern auf einen Hoster mit php7.1 kopieren ...

Zitat:

---

Zitat von Franko

Ok - Danke,
das gilt dann aber nur in Zusammenhang mit der composer.lock.
Wenn ich "nur" die composer.json nehme kann die php Umgebung auf dem Zielserver schon unterschiedlich sein - Oder?

---

Ja. Am Zielserver musst du dann aber auch auf der Konsole die richtige PHP Version verwenden - also die PHP Version, die dein Webserver benutzt. Oder du trägst die PHP Version fix in der composer.json ein.

Zitat:

---

Zitat von Franko

Habe z.B. auf einer Synology Diskstation nur php70 und würde gern auf einen Hoister mit php7.1 kopieren ...

---

Naja, dann ist es sowieso ein Problem. Ich vermute mal du entwickelst auf der Synology Diskstation? Dann bringt es dir auch nichts bspw. die PHP Version in der composer.json einzutragen, denn dann würdest du die Abhängigkeiten für PHP 7.1 bekommen und somit läufst du auf deiner Diskstation in einen Fehler.

Besser wäre wohl in einem Docker Image zu entwickeln, dass exakt die Bedingungen des Live Servers nachbaut. Aber das führt wohl zu weit ;)

Zitat:

---

Zitat von Spooky

Naja, dann ist es sowieso ein Problem. Ich vermute mal du entwickelst auf der Synology Diskstation? Dann bringt es dir auch nichts bspw. die PHP Version in der composer.json einzutragen, denn dann würdest du die Abhängigkeiten für PHP 7.1 bekommen und somit läufst du auf deiner Diskstation in einen Fehler.

---

Ok, Danke
aber wie wäre es dann umgekehrt (nur um die grundsätzliche Vorgehensweise zu verstehen).
Du meinst sicherlich das hier ...

Wenn ich also in einer php71 Umgebung eine php70 Umgebung emulieren möchte damit ich dann diese erzeugte composer.json/lock auf der Diskstation nutzen kann.
Wie sähe dann der Eintrag aus ...

Zitat:

---

Zitat von Spooky

Besser wäre wohl in einem Docker Image zu entwickeln, dass exakt die Bedingungen des Live Servers nachbaut. Aber das führt wohl zu weit ;)

---

Verstanden - Ist angekommen ...

Frank

Dann trägst du zB

Code:

---

"platform": {
    "php": "7.0"
}

---

in deiner composer.json ein.

Zitat:

---

Zitat von Spooky

Dann trägst du zB

Code:

---

"platform": {
    "php": "7.0"
}

---

in deiner composer.json ein.

---

Danke,
reicht dann die generelle Versions Angabe 7.0 oder sollte das bis auf die minor Version z.B. 7.0.24 (hinsichtlich der Ziel Umgebung) identisch sein ...

Kann nicht schaden ;)

Zitat:

---

Zitat von Spooky

Besser wäre wohl in einem Docker Image zu entwickeln, dass exakt die Bedingungen des Live Servers nachbaut. Aber das führt wohl zu weit ;)

---

Docker schaue ich mir an ...

Nachtrag:
Angenommen ich nutze die aktuelle xampp Version mit php7.2 -
könnte man darüber zusammen mit dem composer.json Platform Emulation doch auf jede beliebige, unter Berücksichtigung der Contao System Voraussetzungen,
php version runtergehen - dies nur hinsichtlich der entsprechenden Abhängigkeiten in der composer.lock ...

Sorry,
immer noch Verständnis Fragen:

In der Contao Composer.json steht ja z.B.:

Code:

---

"require": {
        "php": "^5.6|^7.0",

---

Wie ist das dann in Zusammenhang mit einem zusätzlichen Eintrag:

Code:

---

"platform": {
    "php": "7.0.24"
}

---

zu verstehen bzw. wie löst sich dann dann auf?

Habe zum Thema dies hier gefunden: https://github.com/composer/composer/issues/5163 (oder hier)
- aber leider keinen richtigen Durchblick ...

Wenn du

Code:

---

"platform": {
    "php": "7.0.24"
}

---

verwendest werden die Abhängigkeiten der Pakete eben hinsichtlich der PHP Version 7.0.24 aufgelöst.

Code:

---

"require": {
        "php": "^5.6|^7.0"
}

---

steht da nicht im Weg.

Nur zur Info,
habe gerade gesehen das Spooky die grundsätzliche Vorgehensweise in diesem Beitrag bereits Schritt für Schritt erklärt hatte (in Verbindung mit lokaler Installation und Umzug nach 1und1) ...

Mittlerweile könnte aber bei manchen 1&1 Paketen aber auch schon PHP 7.1 auf der Kommandozeile verfügbar sein. Dementsprechend sollte man die Vorgehensweise anpassen.

Zitat:

---

Zitat von Franko

Nur zur Info,
habe gerade gesehen das Spooky die grundsätzliche Vorgehensweise in diesem Beitrag bereits Schritt für Schritt erklärt hatte (in Verbindung mit lokaler Installation und Umzug nach 1und1) ...

---

Ich möchte das f. 1&1 bald testen (bin z.Z. unterwegs). Daher zum Verständnis bitte nochmal. Von Lokal Xampp php 7.2.1 nach 1&1 ...

- lokale Installation
- danach Platform Eintrag in der composer.json entsprechend 1&1 php cli Version setzen
- Lokal composer Update mit deinen Angaben

1) kann ich die lokale Installation so trotz eigentlich php 7.2.1 nutzen oder ist das nur zur Erstellung der .lock gedacht?
2) kann ich die entsprechende composer.json manuell kopieren und den Platform Eintrag setzen und dann composer veranlassen nur die .lock zu generieren ?

- die .json und .lock nach 1&1 kopieren
- composer Installation mit deinen Angaben

3) kann der Platform Eintrag bleiben oder soll der zuvor entfernt werden?

- z. B. später Lokal Erweiterungen installieren
- wieder beide Dateien nach 1&1 kopieren

4) wie lautet dann der korrekte composer Aufruf wieder mi den Autoload optimize Parameter?

Danke


Gesendet von iPhone mit Tapatalk

Zitat:

---

Zitat von Franko

3) kann der Platform Eintrag bleiben oder soll der zuvor entfernt werden?

---

Den Platform Eintrag musst du behalten, wenn die PHP Version am Server niedriger ist, als die Version, mit der du das composer update lokal machst. Umgekehrt ist es eher egal - aber auch nicht unbedingt optimal.

Zitat:

---

Zitat von Franko

4) wie lautet dann der korrekte composer Aufruf wieder mi den Autoload optimize Parameter?

---

Code:

---

composer install -o

---

Zitat:

---

Zitat von Spooky

Den Platform Eintrag musst du behalten, wenn die PHP Version am Server niedriger ist, als die Version, mit der du das composer update lokal machst. Umgekehrt ist es eher egal - aber auch nicht unbedingt optimal.

Code:

---

composer install -o

---

---

Danke, und genau das verstehe ich nicht. Ich dachte der Platform Eintrag erzwingt nur die entsprechenden Angaben in der .lock.
Da dann auf 1&1 genau diese php Version ja vorliegt - warum wird dann der Platform Eintrag noch benötigt zumal ja dann eh nur alles aus der lock gezogen wird ...



Gesendet von iPhone mit Tapatalk

Wenn du auf dem Server die selbe PHP Version hast, die du auch lokal verwendest, brauchst du die Platform Definition nicht.

Davon abgesehen hat das nicht "nur" Auswirkungen auf die composer.lock Datei. Wenn du eine Platform Definition in deiner composer.json definiert hast, werden bei einer composer update (oder require) Operation bei der Abhängigkeitsauflösung genau die Pakete ermittelt (und dementsprechend danach installiert), die zu deiner Plattform Definition passen.

Zitat:

---

Zitat von Franko

Da dann auf 1&1 genau diese php Version ja vorliegt - warum wird dann der Platform Eintrag noch benötigt zumal ja dann eh nur alles aus der lock gezogen wird ...

---

Evtl. Misserverständlich:
Lokal bleibt der Platform Eintrag - wird weiterhin benötigt

Auf 1&1 aber nicht unbedingt
Sofern immer von Lokal -> 1&1 geht

Gesendet von iPhone mit Tapatalk[/]




Gesendet von iPhone mit Tapatalk

Wenn die PHP Version, mit der du das composer update machst, die selbe Version ist, wie die PHP Version, mit der der Web Server (auf dem Zielsystem, wo du composer install ausführst) läuft, dann brauchst du keine Plattform Definition.

Zumindest nicht für PHP - denn es kann noch andere Plattform Abhängigkeiten geben, die hier relevant sind. Wie zB das vorhanden sein von Image Magick (Imagick, Gmagick). Wenn du bspw. lokal Imagick/Gmagick verfügbar hast, am Zielserver, wo du composer install ausführen willst, jedoch nicht, dann gibt es Probleme. Ich glaube aber hier kann man aber keine Plattform Definition machen, die das Vorhandensein von Imagick/Gmagick ausschalten würde.

Danke, wenn das so ist sind aber doch alle bisherigen Beiträge hierzu nicht frei von weiteren Fallstricken - unabhängig der Php Version - auch nicht der Beitrag von Erdmann&Freunde ...

Wenn ich nächste Woche im Büro bin kann ich weiter testen ...

Bitte meine Penetranz richtig einordnen - ich möchte das Thema nur durchdringen - kannst du folgende Annahmen bitte geduldig bewerten:

1) Wenn Lokal und zielserver identische Php Versionen verwenden und nur die composer.json kopiert wird kann es dennoch Probleme hinsichtlich Platform Untersciede geben..
Right?

2) Die composer.lock stellt ein Abbild der jeweiligen, durchgeführten Installation inkl. Php Version dar. Bei Providern die Probleme bei der Abhängigkeits Auflösung haben bzw. aufgrund Restriktionen hierbei abbrechen hilft die vorhandene .lock dies zu umgehen - denn es wird 1:1 herangezogen was in der .lock geschrieben steht
Right?

3) ich benötige keine Platform Definition in der composer .json solange Lokal und zielserver identische Php Versionen haben?
Right?

4) solange Lokal eine andere/höhere Php Version als auf dem zielserver besteht nutze ich Lokal den Platform Eintrag in der composer.json der die Php Version des Zielservers wiederspiegelt
Right?

5) Auch wenn 3) und 4) hinsichtlich Php Version Lokal stimmen kann es weitere Fallstricke bei Platform Unterschieden wie von Dir erwähnt geben
Right?

6) wenn 5) stimmt. Welche Vorgehensweise bleibt denn dann frei von weiteren Fallstricken

...


Gesendet von iPhone mit Tapatalk

Hmm, das mit Imagick interessiert mich jetzt auch, da ich gerade mit lokaler Entwicklung und Deployment auf den Online-Server herumspiele. Ich habe jetzt lokal kein Imagick, wohl aber auf dem Online-Server und will, dass das dann später auf dem Online-Server auch benutzt wird. Kann ich das irgendwie erreichen? Oder muss ich mir dazu zwingend lokal Imagick installieren?

Ich vermute mal, wenn ich nur die composer.json hochlade und composer update ausführe, dann wird es funktionieren? Aber wenn ich die composer.lock auch hochlade und nur ein composer install -o ausführe, um mit weniger RAM auszukommen, dann klappt das mit der Nutzung von Imagick wohl eher nicht?

Sorry, das mit Imagick/Gmagick stimmt (in Bezug auf Contao 4) so natürlich nicht. Erst beim erzeugen des Caches wird festgelegt, welche Bibliothek benutzt wird.

Zitat:

---

Zitat von Franko

1) Wenn Lokal und zielserver identische Php Versionen verwenden und nur die composer.json kopiert wird kann es dennoch Probleme hinsichtlich Platform Untersciede geben..
Right?

---

Wenn du nur die composer.json auf den Server kopierst ist es ohnehin irrelevant, da dann nur ein composer update gemacht werden kann (selbst wenn du composer install eingibst, wird tatsächlich ein composer update durchgeführt), da ja keine composer.lock Datei vorhanden ist.

Zitat:

---

Zitat von Franko

2) Die composer.lock stellt ein Abbild der jeweiligen, durchgeführten Installation inkl. Php Version dar. Bei Providern die Probleme bei der Abhängigkeits Auflösung haben bzw. aufgrund Restriktionen hierbei abbrechen hilft die vorhandene .lock dies zu umgehen - denn es wird 1:1 herangezogen was in der .lock geschrieben steht
Right?

---

Genau, ja.

Zitat:

---

Zitat von Franko

3) ich benötige keine Platform Definition in der composer .json solange Lokal und zielserver identische Php Versionen haben?
Right?

---

Yep (vereinfacht gesagt... denn wie gesagt gibt es ja theoretisch noch mehr Plattform Abhängigkeiten).

Zitat:

---

Zitat von Franko

4) solange Lokal eine andere/höhere Php Version als auf dem zielserver besteht nutze ich Lokal den Platform Eintrag in der composer.json der die Php Version des Zielservers wiederspiegelt
Right?

---

Ja, dann bekommst du lokal zwar unter Umständen ältere Pakete (weil eine ältere PHP Version vorgegaukelt wird), was aber aufgrund der (theoretischen) Rückwärtskompatibilität kein Problem darstellen sollte.

Zitat:

---

Zitat von Franko

5) Auch wenn 3) und 4) hinsichtlich Php Version Lokal stimmen kann es weitere Fallstricke bei Platform Unterschieden wie von Dir erwähnt geben
Right?

---

Theoretisch ja. Praktisch ist, momentan zumindest, die PHP Version der einzige relevante Fallstrick diesbezüglich.