Composer - Updating dependencies Killed

Beim Update einer PE von 6.0.x auf 6.1.4 wird der Composer bei “Updating dependencies” immer vom Server beendet. Der Server hat nur 1GB memory_limit, was sich auf Grund des Shared Hostings auch nicht ändern lässt. Ein Löschen der composer.lock bringt auch keine Änderung.
Die einzige Lösung ist wohl sich den Shop lokal zu installieren, was aber einen großen Aufwand durch den Download der Shopdateien macht.
Anschließend macht man das Update lokal mit “composer update --no-plugins --no-scripts --no-dev” und lädt die composer.lock dann wieder auf den Server und macht “composer update --no-dev”.

Wie kann man das umgehen oder lösen?

Ist das eine Frage oder eine Aussage? Wenn du composer update ausführst wird ja die composer.lock neu geschrieben und so die soeben hochgeladene wieder überschrieben.

Was genau?

Also ich habe das durch eine minimierte composer.json gelöst da sonst immer memory-Fehler auftraten:

{
“name”: “oxid-esales/oxideshop-project”,
“type”: “project”,
“description”: “This file should be used as an OXID eShop project root composer.json file. Entries provided here intended to be examples and could be changed to your specific needs.”,
“license”: [
“GPL-3.0-only”
],
“minimum-stability”: “stable”,
“require”: {
“oxid-esales/oxideshop-metapackage-ce”: “^v6.1.4”
}
}

Sorry, gemeint war hier nicht “composer update”, sondern composer install, um die gerade lokal erzeugte composer.lock zu nutzen. Hatte diese Möglichkeit gefunden (aber noch nicht getestet), finde Sie aber bei mehreren Projekten zu umständlich in der Anwendung.

Die Frage war, ob es eine andere Lösung gibt (ohne eine lokale Installation zu nutzen).

Also lokal entwickeln ist eigentlich ein Muss.

Du kannst aber auch mit Gitlab CI arbeiten. Du pusht dann alles in dein privates Gitlab-Repo (Von wo auch immer) und Gitlab baut dann den Shop mit allen NodeJS & Composer Abhängigkeiten und schreibt dir alles mit Rsync oder Git auf deine Live- bzw Dev-Umgebung.

Das ist relativ einfach eingerichtet, Gitlab hat tonnenweise nützlich Tutorials und Infos dafür. Diese Methode benötigt allerdings einen SSH-Zugang.

Ohne composer.lock benötigt Composer 2-4Gb Speicher, mit composer.lock nur 300Mb - 900Mb.

Sehe ich auch so. Bei composer install werden die Dateien nicht von vendor nach source kopiert, das kann man machen indem man danach

composer run-script post-update-cmd

ausführt.

Das passt gerade gut hier her:
https://community.contao.org/de/showthread.php?74042-Contao-amp-Laragon-Schritt-für-Schritt-zur-lokalen-Entwicklungsumgebung-unter-Windows&highlight=laragon

Dieses Tutorial beschreibt zwar die Installation von Contao, ich benutze Laragon aber auch für OXID. Geht super!

@DayanaLudecke: Auch wenn es schon eine Weile her ist:

Die Argumente der Vorredner sind alle berechtigt, aber eine weitere Lösung des Speicherproblems ist bereits schon, wenn Du aus dem require in Deiner root-composer.json den Punkt “oxid-esales/oxideshop-metapackage-ce”: “^v6.1.4” rausnimmst und stattdessen den Inhalt aus dem require der composer.json des “oxideshop-metapackage-ce”-Repositories direkt vermerkst. Dann kannst Du auch gleich unnötige Zahlungsmodule und Demo-Installer entfernen.
Dieses Verschieben der dependencies-Ebenen verbraucht bereits deutlich weniger Speicher.
Knackpunkt ist, das wenn es demnächst ein Update auf eine neue Version gibt, Du dann den Inhalt Deines requires mit dem der neuen oxideshop-metapackage-ce Zeile für Zeile abgleichen musst.
Aber das ist mglw. ein Wermutstropfen gegenüber der wieder erschaffenen Möglichkeit des composer-updates.

Letztens gefunden --> https://blog.oxidmodule.com/archives/760-OXID-Shop-schon-vor-der-Installation-individualisieren.html

Hol Dir mal diese RSS-Feeds, Steffen :wink:
https://oxidforge.org/en/feed/
https://oxidforge.org/de/feed/