Bei Installation eines Bundles die automatische Auswahl einer inkompatible Version verhindern

[BugBuster1701]

Composer wie auch der Manager nehmen ohne Versionsangabe einfach die neueste Version und versuchen die zu installieren.
Beispiel: Habe ich ein Contao 4.4 und suche nach bugbuster/contao-be_user_online-bundle wird als neuste Version die 2.0.0 versucht zu installieren, obwohl die erst ab Contao 4.5 freiegegeben ist.

Könnte der Manager das irgendwie abfangen und eine kompatible Version selbst wählen, oder wenigstens drauf Hinweisen, "aktuelleste Version von ... nicht kompatible mit der installieren Contao Version, bitte ein kompatible Versionsangabe eingeben" oder so ähnlich?
Der Manager weiß ja welche Contao Version installiert ist.

[aschempp]

Diese Auflösung macht Composer, das ist leider nicht möglich.

[Aybee]

Ist dies ein Fehler im Composer? Denn er ist doch genau dafür da, die Abhängigkeiten zu checken und wenn in einer Erweiterung steht "erst ab Contao 4.5", wieso nimmt er sie denn dann trotzdem bei 4.4?

[Toflar]

Nein, das ist kein Fehler. "Eine kompatible Version" heisst, er müsste jede Version in Kombination mit allen anderen Paketen die du bereits hast prüfen. Also er müsste die Abhängigkeitsauflösung die so lange dauert und wegen RAM-Issues in die Cloud ausgelagert wurde für jede einzelne Version des Pakets durchführen. Es geht ja hier nicht nur um Contao sondern immer um alle Abhängigkeiten und deren Abhängigkeiten und wiederum deren Abhängigkeiten. Schlussendlich brauchst du ein installierbares Set an Paketen.

[Aybee]

Die Hintergründe und technischen Probleme kenne ich nicht. Ich gebe aber zu bedenken, dass der Befehl "neueste Version" gefühlt nicht richtig sein kann. Er müsste "neueste kompatible Version" lauten. Das wurde ja bereits im ER2 verhindert, dass man eine Erweiterung, die erst ab C3.5 freigegeben war in C3.4 installieren konnte, bzw. man zumindestens einen Hinweis bekam.

D.h. jetzt also, dass, wenn ich ein Paket installiere, ich zuerst manuell bei Packagist nachsehen muss, ob die für meine Contao Version freigegeben ist. Und hier geht es um C4.5, C4.7 ist laut Releaseplan aber auch bereits in der Entwicklung. Und wenn dann noch C5 und C6 kommt?

Irgendwie hatte ich mir das einfacher vorgestellt, und zwar, dass ich mit "Nach Paketen suchen" kompatible Bundles zu meiner Contao Version angezeigt bekomme.

Und wenn ich jetzt Contao aktualisiere, muss ich meine Pakete checken, welche ich in der Version heruntergesetzt habe und ob ich sie jetzt wieder hochsetzen muss/kann?

[Toflar]

Korrekt. Du bist verantwortlich zu schauen, welche Pakete überhaupt in Frage kommen könnten, weil es kann niemand im Voraus wissen, ob das was du gerne hättest schlussendlich zu einer installierbaren Kombination führt. Nur weil die neue Version zu Contao kompatibel ist, heisst ja nicht, dass sie dann in Kombination mit anderen Erweiterungen läuft.

[Aybee]

Aber könnte man dies nicht zumindestens automatisiert prüfen, ob in der composer.json der Erweiterung die Contao Version übereinstimmt? Mit Computern müsste man doch sone Aufgabe übernehmen können, oder?

[aschempp]

Theoretisch, ja. Wie gesagt übernimmt diese Aufgabe aber Composer, und Composer weiss nichts von einer Contao Version. Dazu müssten wir die entsprechenden Funktionen von Composer komplett nachbauen, was wohl nicht ganz einfach wird …

[Aybee]

metamodels/core z.B. wird bei den Paketen im Manager als "inkompatibel" angezeigt. Bei den Paketdetails sieht man contao/core: ^3.5.5
https://packagist.org/packages/metamodels/core

Ist dies der Grund, warum es als inkompatibel angezeigt wird? Wenn ja, dann wäre es natürlich gut, wenn dies auch funktionieren würde, wenn die Version zu groß ist, nicht nur, wenn Contao zu klein ist.

[Aybee]

Mmh, metamodels/filter_perimetersearch wird nicht als inkompatibel angezeigt und hat auch contao/core: ^3.5.5
https://packagist.org/packages/metamodels/filter_perimetersearch

[Aybee]

Ihr wisst doch bestimmt, wer diese Entscheidung trifft und warum, oder?

"inkompatibel": "Dieses Paket wird in der Contao 4 Managed Edition nicht unterstützt."

[aschempp]

Jetzt wechselst du aber das Thema… Das Paket ist inkompatibel, diese Entscheidung trifft das Entwicklerteam. contao/core: ^3.5.5 ist nicht Contao 4 😉

[Aybee]

Ich denke, dass dies alles hier zu dem Thread-Title passt:

"Bei Installation eines Bundles die automatische Auswahl einer inkompatible Version verhindern"

Thumbs Up Emoji von @leofeyer verstehe ich nicht.

Das Entwicklerteam entscheidet also, dass z.B. metamodels/filter_perimetersearch kompatibel ist, obwohl Requires contao/core: ^3.5.5? Und bugbuster/contao-be_user_online-bundle auch, obwohl Requires contao/core: ~4.5?

Wie gesagt, ich kenne die teschnichen Hintergründe und Verbindungen nicht, aber es geht darum, dass der Manager "eine inkompatible Version verhindern" soll, wie im Thread-Title angefragt. Teilweise zeigt er es ja auch schon an mit dem Text, den ich oben zitiert hatte.

[aschempp]

Sorry, mit Entwicklerteam meinte ich natürlich das Team von MetaModels. https://packagist.org/packages/metamodels/filter_perimetersearch#dev-feature/contao4 ist als kompatibel mit Contao 4 definiert, daher erscheint es. Genauso bei allen anderen. Der Manager kann nur sicherstellen dass es für das Paket eine Version für Contao 4 / den Manager gibt, nicht ob diese Version auch mit allen deinen Abhängigkeiten kompatibel ist. Dafür sorgt dann Composer bei der Installation.

[Aybee]

Wenn man von dem Manager aus über "Paketdetails" nach metamodels/filter_perimetersearch geht landet man erstmal hier https://packagist.org/packages/metamodels/filter_perimetersearch. Dort sieht man dann Requires contao/core: ^3.5.5. Dort sieht man eine Liste mit Versionen.

• dev-master / 2.0.x-dev
• 2.0.2
• 2.0.1
• 2.0.0
• 2.0.0-alpha2
• 2.0.0-alpha1
• 1.1.0-alpha1
• 1.0.0
• dev-hotfix/2.0.3-translation
• dev-feature/contao4
• dev-hotfix/2.0.2-translation
• dev-develop
• dev-hotfix/2.0.3
• dev-hotfix_sql-to-dca
• dev-hotfix_travis_composer

Muss man sich dann dort in der Liste noch eine Version suchen, die für Contao 4.4 geeignet ist?

Der Manager kann nur sicherstellen dass es für das Paket eine Version für Contao 4 / den Manager gibt, nicht ob diese Version auch mit allen deinen Abhängigkeiten kompatibel ist. Dafür sorgt dann Composer bei der Installation.

Also Version 4 wird gecheckt? 4.5 nicht mehr? Wenn ja, dann wäre es schön, wenn ihr dies irgendwie hinbekommt, dass auch auf die zweite Ziffer von Contao gecheckt wird.

Ich habe jetzt mal den "Testlauf" für bugbuster/contao-be_user_online-bundle gemacht. Dieser wird tatsächlich nicht bestanden wenn die Version auf "Neueste Version" steht. Wenn ich dort "1.0.2" eintrage, wird der Testlauf bestanden. Allerdings ist der Hilfetext

Dieses Paket wird in der besten verfügbaren Version installiert, wenn Sie die Änderungen anwenden.

nicht besonders hilfreich. Dort könnte ein Hinweis darauf enthalten sein, dass man die Pakete bei packagist.org auf Kompatibilität prüfen muss. Zumal der Hinweis immer noch erscheint, nachdem man den Button "Änderungen prüfen" geklickt hat. Daraufhin erscheint auch erst der Button "Testlauf". Spätestens jetzt wäre ein Hinweis im Hilfetext von Vorteil um darauf hinzuweisen, das der Testlauf durchgeführt werden sollte um die Kompatibilität sicherzustellen.

[frontendschlampe]

Composer möchte immer die aktuellste Version einer Erweiterung installieren. Bei bugbuster/contao-be_user_online-bundle ist das die 2.x - diese ist aber erst ab Contao 4.5.x kompatibel. Also nicht mit Contao 4.4.x - somit kann die Version 2.x nicht mit Contao 4.4.x installiert werden. In der Paketverwaltung unter Contao 3.5.x wurde das jedoch geprüft und es stand die für die entsprechende Contao kompatible Version automatisch zur Installation bereit.

Genau diese Funktion gibt es aktuell beim Manager auch. Denn wenn ich versuche bugbuster/contao-be_user_online-bundle auf Contao 4.4.x zu installieren, dann ist die neuste Version durchgestrichen und zeigt mir schon, dass ich diese Version nicht installieren kann:

Das einzigste, was der Manager jetzt nicht macht, ist eine Versionsauswahl anzuzeigen. Ich muss mir eine geeignete Version über Packagist oder Github selbst raussuchen und entsprechend eingeben. Das ist natürlich eine kleine Hürde für alle die, die mit den Versionsstrings nicht so richtig was anfangen können. Schöner wäre es natürlich, wenn ich über das Zahnrad mir eine kompatible Version aussuchen könnte, ohne dass ich den Versionsstring manuell eingeben muss.

In meinem Test konnte ich feststellen, dass Composer versucht in der aktuellsten Major-Version von bugbuster/contao-be_user_online-bundle, also der 2.x, eine Version zu finden, die mit Contao 4.4.x kompatibel ist. Aber natürlich findet er im Bereich der Version 2 keine. Eine andere Major prüft er nicht, z.B. die 1.x.

Was die Erweiterung metamodels/filter_perimetersearch so ist diese in keiner Version mit Contao 4 kompatibel. Auch das wird im Manager angezeigt:

Muss man sich dann dort in der Liste noch eine Version suchen, die für Contao 4.4 geeignet ist?

nur, wenn die aktuellste stabile Version von metamodels/filter_perimetersearch nicht mit der installierten Contao-Version kompatibel ist.

Also Version 4 wird gecheckt? 4.5 nicht mehr? Wenn ja, dann wäre es schön, wenn ihr dies irgendwie hinbekommt, dass auch auf die zweite Ziffer von Contao gecheckt wird.

Es wird nur gescheckt, ob die aktuellste Version einer Erweiterung mit der installierten Contao-Version kompatibel ist. Also wenn du 4.5 installiert hast und die aktuellste stabile Version von metamodels/filter_perimetersearch, also die 2.0.2, Contao 4.5 unterstützt, dann kannst du sie auch installieren.

[BugBuster1701]

Dieses durchgestrichende "neuste Version" habe ich aber auch erst beim drittem mal hinsehen erkannt.
Das sollte man vielleicht mal deutlicher hervorheben.
Es sagt aber einen unerfahrenden Nutzer aber auch nicht, das er nun selber hand anlegen muss.
Ich lese das so, "die aktuelleste bekommste nicht, aber eine ältere (kompatible) wenn du auf Paket hinzufügen klickst"
Was ja leider nicht der Fall ist.

[Aybee]

Ok, sieht so aus, als würden wir uns nähern.

Wenn ich bei den Paketen nach easy suche, dann findet er bei mir 11 Erweiterungen, welche nicht als "verwaist" oder "inkompatibel" gemarkt sind.

Davon ist bei mir nur eine nicht mit "neueste Version durchgestrichen" gemarkt und zwar terminal42/contao-easy_themes https://packagist.org/packages/terminal42/contao-easy_themes (evtl. hatte ich die irgendwann schonmal manuell auf ^2.2 gesetzt, kann mich aber nicht daran erinnern.)

Requires
    php: >=5.4
    contao/core-bundle: ~3.2 || ^4.4.1
    contao-community-alliance/composer-plugin: ~2.4 || ~3.0

ma3xl3/contao-easy-favicon z.B. ist "neueste Version durchgestrichen" obwohl

Requires
    php: ^5.6|^7.0
    contao/core-bundle: ^4.4
    chrisjean/php-ico: ^1.0.4

https://packagist.org/packages/ma3xl3/contao-easy-favicon#dev-master

Warum wird die nun nicht in Version 2.0.1 angeboten? Die anderen habe ich nicht überprüft.

[aschempp]

In der Suche sind alle durchgestrichen und grau, welche du noch nicht installiert hast 😉
Erst wenn du das Paket zur Installation vormerkst kannst du eine Version setzen. Vielleicht ist das durchgestrichen gar nicht nötig …

[Aybee]

Eine Doku zum richtigen Umgang bei der Auswahl von Paketen wäre nicht schlecht. Evtl. helfen aber auch schon verbesserte Hilfetexte.

[kroerig]

Was ich auch festgestellt habe: Wenn ich einmal einen festen Versionszweig einstellen musste, z.B. 1.x, dann bleibe ich auf alle Erweigkeit auf dieser Version hängen, auch wenn es inzwischen schon V 2.x gibt. Was dann dazu führt, dass die Installation anderer Erweiterung fehlschlägt, weil Composer die Abhängigkeiten nicht mehr gelöst bekommt, da diese eine Erweiterung ihn ggf. zwingt eine Abhängigkeit zu einer älteren Version zu erhalten, die aber gar nicht nötig wäre.

Ich bin hier auch für Lösung, die Kompatibilitäten im Contao-Manager berücksichtigt. Wenn es doch zu jedem Paket eine Beschreibung der Mindestanfordungen gibt, dann könnte der Contao-Manager die doch auch abrufen und auswerten bevor und dann dem Composer die Anweisung erteilt das Paket in einer bestimmten Version zu installieren.

Ebenso sollte die Funktion "Pakete aktualisieren" auch schauen, ob es eine neue Major-Version gibt und diese ggf. zur Installation vormerken.

[aschempp]

Ebenso sollte die Funktion "Pakete aktualisieren" auch schauen, ob es eine neue Major-Version gibt und diese ggf. zur Installation vormerken.

Der Manager kann nicht entscheiden welche Version installiert werden soll, diese Entscheidung trägt der Nutzer. Eine neue Major-Version ist (per Definition) inkompatibel zum bestehenden, also z.B. nicht kompatibel zur bestehenden Datenbank und benötigt ein manuelles Update. Das kann der Manager niemals übernehmen.

[kroerig]

@aschempp Und wie soll dann der normale Contao Nutzer mitbekommen, dass es jetzt Version 2 einer Erweiterung gibt? Ich rede jetzt nicht vom professionellem Admin, sondern vom ganz normalen Anwender, der z.B. die Vereinshomepage mit Contao betreibt?

Auch wenn der Manager eine neue Major-Version nicht automatisch zur Installation freigibt, so sollte er aber zumindest mitteilen, dass es sie gibt. Denn irgendwann kommt eine Erweiterung an den Punkt, wo ein Versionswechsel ansteht. Und dann werden Sicherheitslücken und Fehler auch nur noch in der neuen Version behoben. Oder noch "schlimmer" ist der Effekt bei Versionsnummer <1. Siehe dazu auch: https://community.contao.org/de/showthread.php?72441-CM-Composer-Hinweise&p=485887&viewfull=1#post485887

[aschempp]

Mehrere Gedanken dazu:

• Muss der normale Contao Nutzer das mitbekommen? Seine Webseite funktioniert ja, warum muss er updaten?
• Von einem Administrator erwarte ich, dass er sich mit seiner Installation auseinander setzt. Das bedeutet er muss halt ggf. im Forum lesen oder die Erweiterungen besuchen, um zu sehen ob sich etwas für Ihn geändert hat.
• Dasselbe gilt ja für Contao. Der Manager macht kein Contao Minor Update, weil dabei Dinge kaputt gehen können. Der Administrator muss sich damit beschäftigen.

Natürlich wäre es schön wenn der Manager sowas könnte. Aber aktuell haben wir diese Informationen nicht, und ich wüsste nicht woher wir sie bekommen. Auch nicht wie diese dem Benutzer angezeigt werden sollen. Insbesondere so dass er nicht einfach ein Major-Update und damit seine Installation kaputt macht.

Ein Auswahl der Paketversion wie bei Contao 3.5 wäre ein logischer Schritt. Aber wie genau dies in den Manager integriert werden soll ist noch nicht klar.

[dmolineus]

@aschempp Und wie soll dann der normale Contao Nutzer mitbekommen, dass es jetzt Version 2 einer Erweiterung gibt? Ich rede jetzt nicht vom professionellem Admin, sondern vom ganz normalen Anwender, der z.B. die Vereinshomepage mit Contao betreibt?

Eine Möglichkeit ist sich bei Github zu registrieren und entsprechende Erweiterungen zu "watchen". Neuerdings ist es möglich sich auch nur über Releases informieren zu lassen. Alternative wäre ein Dienst wie Libraries.io.

[ausi]

Ich finde es auch verwirrend, dass die Installation eines Paketes fehlschlägt weil Composer eine „zu neue“ Version automatisch wählt. Siehe auch https://community.contao.org/de/showthread.php?80657

Beispiel: Habe ich ein Contao 4.4 und suche nach bugbuster/contao-be_user_online-bundle wird als neuste Version die 2.0.0 versucht zu installieren, obwohl die erst ab Contao 4.5 freiegegeben ist.

Könnte der Manager das irgendwie abfangen und eine kompatible Version selbst wählen,…

Für Neuinstallationen eines Paketes könnte der Manager standardmäßig die Version * anfordern und nach der Installation das Version-Constraint auf die tatsächlich installierte version plus ^ am Anfang setzen.

Das wäre aus meiner Sicht für die Nutzer die beste Lösung, aber vermutlich technisch nicht so leicht umzusetzen.

[aschempp]

Für Neuinstallationen eines Paketes könnte der Manager standardmäßig die Version * anfordern und nach der Installation das Version-Constraint auf die tatsächlich installierte version plus ^ am Anfang setzen.

Hört sich nach etwas an, was Composer tun sollte, denn dann wäre das Problem für alle Paket-Installationen gelöst? 😉

[ausi]

Denke auch. Auf der cli will ich ja bei composer require foo/bar auch keine inkompatible version. Das wäre schon für alle Composer Nutzer ein gutes Feature IMO.

[kroerig]

Ich bin gerade wieder auf diesen Effekt gestoßen. Der CM zeigt mir bei einer Erweiterung an, dass es eine neuere Version 1.7 gibt. Ich habe bei mir ^1.6 eingestellt. OK, wenn es jetzt 1.7, dann passe ich mal meine Version an.
Die ließ sich dann aber nicht installieren, wie mir die Composerausgabe dann gezeigt hat, denn V1.7 braucht Contao 4.13, ich habe aber noch 4.9.

Könnte man dem VM beibringen, dass er bei der Anzeige "neue Version verfügbar" berücksichtigt, ob diese Version auch zum installierten Contao passt?

[Toflar]

Das würde nicht wirklich was bringen weil vielleicht passt nicht nur Contao nicht sondern eben etwas in den anderen abhängigen Paketen. Genau das ist die Aufgabe, die Composer übernimmt. Er findet die bestmöglichste Lösung für alle definierten Abhängigkeiten und deren Abhängigkeiten (und deren, und deren...). In Contao 4.13 ohne Extensions sind das aktuell ungefähr 90.000 Regeln, die zu berücksichtigen sind :) Die kann man nicht live berechnen.

[kroerig]

In meinem Fall geht es nicht ums berechnen, sondern einfach die Mindestanforderung zu berücksichtigen. Wenn eine Erweiterung erst ab Contao Version X lauffähig ist, dann reicht hier eine Bedingung aus um nicht-kompatible Versionen gar nicht erst anzubieten,

Dann kommt man nämlich a) erst gar nicht auf die Idee eine neuere Version installieren zu wollen und b) muss man, wenn das mehrere Erweiterungen betrifft nicht erst bei allen schauen, ob die überhaupt lauffährig sind.

[Toflar]

Und was, wenn die 1.7.0 nicht kompatibel mit der installierten Contao-Version ist? Zeigen wir eine tiefer an? Und was wenn die nicht? Und was wenn die nächste nicht? ....
Und wenn wir schon Contao testen, können wir dann nicht auch die PHP-Version testen? Und die PHP-Extensions? Und...und...?

[fritzmg]

In meinem Fall geht es nicht ums berechnen, sondern einfach die Mindestanforderung zu berücksichtigen. Wenn eine Erweiterung erst ab Contao Version X lauffähig ist, dann reicht hier eine Bedingung aus um nicht-kompatible Versionen gar nicht erst anzubieten,

As already explained, the Contao requirement is not the only requirement.

[kroerig]

Ja, es ist nicht die einzige Abhängigkeit, aber die größte. Und wenn der CM schon anzeigt, dass es eine neue Version einer Erweiterung gibt, dann sollte er zumindest die einfachste Bedingung prüfen, nämlich ob die mindest-Contao-Version installiert ist.
Für diese Anzeige wird ja keine Composerberechung durchgeführt, sondern nur im Repository nachgeschaut.

[aschempp]

Die Anzeige basiert auf deiner Eingabe und der verfügbaren Version. Wenn du möchtest dass die 1.7 nicht vorgeschlagen wird (weil du weisst dass sie zu deinen Abhängigkeiten nicht passt), kannst du in der Versionsbedingung z.B. 1.6.* eintragen. Unabhängig davon hat das mit dem Originalticket nichts zu tun (hier geht es um die initiale Installation eines Pakets).

[ausi]

Alle meine (RockSolid Themes) Pakete sind nun davon betroffen und lassen sich in Contao 4.9 ohne Versionsangabe nicht mehr installieren 😕

Ich werde mir mal den Lösungsvorschlag aus #325 (comment) ansehen und eventuell bei Composer vorschlagen.

[ausi]

Eventuell ließe sich das Problem durch den neuen composer bump command beheben. Also:

1. Zuerst composer require xxx:*
2. Danach composer bump xxx

[Toflar]

bump würde nichts tun. * bleibt unangetastet.

[aschempp]

Ich denke wir werden dieses Problem mit Contao 5 in Zukunft sehr oft haben.
Leider nützt uns composer/composer#11160 auch nichts, da wir composer update immer getrennt von composer require machen. Eine Möglichkeit wäre dass der Contao Manager selber require * macht und dann die Versionsbedingung auf die passende Minor-Version einschränkt.

[aschempp]

Einzige Alternative aus meiner Sicht wäre im Manager die Auswahl einer Version zu erlauben (oder zu erzwingen), dann ist der/die Anwender:in selber dafür verantwortlich. Hätte den Vorteil dass man auch eine bestehende Version "per Auswahl" hochziehen kann.

[Toflar]

Ich glaube dank der jüngsten Optimierungen in Composer selbst, sollte ein composer require vendor/package --no-install in den meisten Fällen problemlos durchlaufen.
Die Versionsbedingung muss dank composer/composer#11160 nicht mehr selber angepasst werden, es passiert automatisch.
Also wenn du zukünftig in Composer composer req madeyourday/contao-rocksolid-slider machst, ohne Versionsangabe, wird er dir bei Contao 4.9 ^2.1 eintragen und bei 4.13 ^2.2. Also exakt das, was wir wollen 😊

[aschempp]

leider verwenden wir --no-update, womit das Problem bei uns weiterhin besteht 😢

[Toflar]

Composer 2.5 wurde veröffentlicht, deswegen habe ich mir das nochmal genauer angeschaut. Folgende Feststellungen:

• Beim Contao Manager mit Cloud-Betrieb (Standard) ist es eigentlich richtig, composer require mit --no-update laufen zu lassen. Und zwar deshalb, weil man eben konfiguriert hat, dass der Resolving-Prozess auf der Cloud laufen soll. Wird composer require ohne --no-update ausgeführt, wird der Solver bedient und das sorgt für den Resolving-Prozess.
• Früher hat dieser Prozess Gigabytes an RAM gefressen. Deswegen war --no-update nicht nur richtig, sondern auch unerlässlich.
• Mit den Verbesserungen am Solver in Composer über die vergangenen Jahre - an denen wir ja massgeblich auch beteiligt waren - ist der RAM-Verbrauch aber mittlerweile wirklich drastisch gesunken.
• Dies gilt insbesondere für composer require <paket> (ohne -w oder -W). Denn hier wird ein sog. "partial update" vollzogen. Es werden also nicht alle Möglichkeiten geprüft, sondern nur die Abhängigkeiten des zu installierenden <paket> - die anderen Pakete werden als "müssen auf ihrer Version bleiben" (fixed) betrachtet (dieses Verhalten lässt sich mit -w bzw. -W beeinflussen, was der Manager aber noch nie unterstützt hat).
• Ich habe mal ein composer require terminal42/notification_center auf einem meiner grössten Projekte laufen lassen. Mit Composer 2.4.* bekomme ich wie zu erwarten einen Fehler, weil er versucht, Version 1.7.0 zu installieren. Mit Composer 2.5 resolved er eben und stellt fest, dass 1.7.0 nicht geht und nimmt ^1.6. Unser gewünschtes Verhalten. Die dafür benötigten Ressourcen betrugen: Memory usage: 30.89MiB (peak: 105.73MiB), time: 2.84s.
• Man sieht, 105.73MiB RAM waren für die Entscheidung nötig. Auch bei einem vollständigen composer update, werden im Schnitt kaum je mehr als 180MB RAM verwendet. Wir können das an der Statistik der Cloud nachvollziehen: https://www.composer-resolver.cloud/clients
• Wir müssen aber trotzdem auch festhalten, dass es immer Ausreisser geben kann, die mehr RAM beanspruchen.
• Wir sollten auch nicht vergessen, dass die Cloud nicht nur das Ressourcen-Problem löst, sondern auch sonst diverse Hosting-Provider-Quirks abfängt.

Ich sehe folgende Optionen:

1. Wir belassen es wie's ist. Wir sollten dann aber zumindest darüber nachdenken, --no-update nur im Cloud-Fall zu nutzen und nicht in beiden.
2. Wir bauen die Cloud komplett aus.
3. Wir bauen den Manager so um, dass er nie --no-update nutzt.
   a) Wir machen das in allen Fällen.
   b) Wir machen das bspw. nur, wenn im Web mind. 256MB RAM zur Verfügung stehen. Wir gehen davon aus, dass bei geforkten Background-Prozessen mind. genauso viel zur Verfügung stehen.

Dann würde mir noch eine weitere Möglichkeit einfallen, die ggf. für uns sogar der Königsweg darstellen könnte, da er am wenigsten Einfluss auf die aktuelle Logik hat:

4. Wir bauen eine weitere, vorgängige Operation ein, die im Prinzip statt composer require terminal42/notification_center --no-update ein composer require terminal42/notification_center --dry-run laufen lässt. --dry-run sorgt dafür, dass der Resolver läuft, wird aber nichts installieren oder updaten. Es ist also eine Operation die nichts am System ändern würde. Der Output von Composer würde sowas enthalten: Using version ^1.6 for terminal42/notification_center. Wir parsen diesen Output und lassen dann unsere bestehende RequireOperation mit composer require terminal42/notification_center:^1.6 --no-update laufen. Also quasi eine optionale Versionseinschränkung auf Basis einer vorgelagerten Operation.
   a) Wir machen das in allen Fällen.
   b) Wir machen das bspw. nur, wenn im Web mind. 256MB RAM zur Verfügung stehen. Wir gehen davon aus, dass bei geforkten Background-Prozessen mind. genauso viel zur Verfügung stehen.

Das würde das Problem potenziell für die meisten User lösen.

[aschempp]

Ich denke nicht dass wir realistisch von --no-update wegkommen, weder mit noch ohne Cloud. Beispielsweise weil wir gleichzeitig requires, removes und selektive Updates können. Ausserdem aktivieren wir vor dem Install den Wartungsmodus (was dann aber eher --no-install ist).

Ich sehe Option 4 als idealer, allerdings ist Output-Parsing nicht besonders schön. Eine weitere Option die mir einfällt:

5. wir machen ein composer require terminal42/notification_center:*, lassen Composer die neuste mögliche Version installieren und pinnen danach diese selber in der composer.json. Innerhalb eines Update-Tasks dürfte das relativ einfach sein, da wir wissen welche Pakete gerade installiert wurden und nach dem Update wissen wir auch deren Versionen. Einziges "Problem" ist dann, dass der composer.lock Hash out-of-sync ist. Aber afaik können wir den sogar selber wiederherstellen.

WDYT @Toflar ?

[MDevster]

Unabhängig von den Varianten 4 und 5 und dem Zeitraum der Umsetzung, finde ich die reine Anzeige der kompatiblen Versionen einer Erweiterung zur bestehen Contao Installation als besonders Hilfreich. (Siehe Paketverwaltung von Nicky). Die Liste der Versionen müsste halt als "voraussichtlich kompatibel" zu der Installation gekennzeichnet werden und es muss auch nicht jedes mögliche Szenario berücksichtigt werden.

Ganz nüchtern betrachtet sehe ich dadurch folgende Vorteile:

1. Auch wenn der Anwender bei packagist.org die passende Version heraussucht, ist nicht gesagt das er diese auch installieren kann -> in 95% der Fälle Contao + Erweiterung würde es aber funktionieren, also warum nicht gleich anzeigen.
2. Der Anwender sieht auf einen Blick das es neue Versionen oder ältere Versionen gibt die eventuell passen und kann dann selbst recherchieren -> Enormer Vorteil zur jetzigen Ansicht.
3. Aus der Liste der Versionen kann direkt auf die Release Info der Version bei packagist.org verlinkt werden.
4. Bei klick auf eine bestimmte Version kann die Versionsnummer für die Installation gleich übernommen werden -> viele Anwender kommen mit den Angaben "^2.3" schlecht klar -> Aber genau für diese Anwender ist ja der Manager eigentlich da.
5. Evtl. vorhandene Readme oder Changelog Inhalte könnten direkt verlinkt werden.
6. Der Anwender sieht das die letzten Versionen nur noch für eine bestimmte PHP Version / Contao Version veröffentlicht wurden und ist eher gewillt auch seine Installation upzudaten.
7. Die Liste könnte weniger "technisch" sein, dafür gibt es ja schon packagist.org.

Ich werde in den nächsten Tag mal einen entsprechenden Entwurf bereitstellen, David hat sich dem Thema bereits angenommen.

[Toflar]

5. wir machen ein composer require terminal42/notification_center:*, lassen Composer die neuste mögliche Version installieren und pinnen danach diese selber in der composer.json. Innerhalb eines Update-Tasks dürfte das relativ einfach sein, da wir wissen welche Pakete gerade installiert wurden und nach dem Update wissen wir auch deren Versionen. Einziges "Problem" ist dann, dass der composer.lock Hash out-of-sync ist. Aber afaik können wir den sogar selber wiederherstellen.

Das ist ja genau das was composer require seit Composer 2.5 macht. Ohne Versionsangabe nimmt er *, übergibt das dem Solver und passt nach dem Resolving die composer.json auf den passenden Constraint an (und schreibt eben Using version <version> for <package> auf die CLI) und passt den composer.lock Hash an.

[Metis77]

Für mich reichen hier die Composer Fehlermeldungen ...
Da kann man schon sehr gut rauslesen, was mit was nicht kompatibel ist.
Für mich also ok.

Für meine Kunden aber ganz sicher nicht.
Die klicken voller Zuversicht, weil Sie ein tolles Plugin gefunden haben, auf das angebotene "Paket hinzufügen" und verstehen (wie ich finde zurecht) die Welt nicht mehr, wenn dann für sie kryptische Fehlermeldungen kommen.

Bitte nicht arg böse sein, ob des folgenden Vergleichs.
Aber ein Blick über den Tellerrand ist im Tellerwettbewerb nie verkehrt.
Ich selbst arbeite sonst neben Contao nur mit Craft CMS. Bei denen läuft auch Composer im Hintergrund (hinter der Manager ähnlichen GUI). Und die bieten bei Major Updates einen Systemcheck, der mir angibt, ob das MajorUpdate überhaupt funktionieren kann. Es werden dann vorher Sachen geprüft die PHP und MySQL Versionen aber eben auch, ob alle Plugins zumindest auf dem Papier (der composer.json) kompatibel wären.

Und viel wichtiger:
In der Plugin Liste vom GUI werden mir Plugins, die nicht zur aktuellen Major Version des Systems passen, gar nicht erst angezeigt.

Ich denke, wenn mann man ein GUI wie den Contao Manager anbietet, damit Contao auch Leute installieren können, die consolen Fehler per se nicht lesen können/wollen, dann darf man sich nicht wundern, wenn eben diese User des GUIs an inkompatiblen Plugins scheitern.

Deshalb denke ich, es wäre sehr sinnvoll, am Composer vorbei, einen Vorabcheck im Contao Manager zu integrieren.
Vermutlich würde es reichen, wenn dieser prüft, ob die Major Version passt.

[fritzmg]

@Metis77 feel free to create a PR ;)

[Metis77]

@Metis77 feel free to create a PR ;)

Klar, wenn ich das könnte ;)
Aber ich entnehme deiner Antwort eine gewisse grundsätzliche Zustimmung ;)

[ausi]

In der Plugin Liste vom GUI werden mir Plugins, die nicht zur aktuellen Major Version des Systems passen, gar nicht erst angezeigt.

@Metis77 in diesem ticket geht es aber (denke ich) um etwas anderes, und zwar dass bei der installation einer Erweiterung automatisch die neueste Version die mit dem System kompatibel ist installiert wird (aktuell kann es vorkommen dass Composer versucht eine zu neue version zu installieren).

Unabhängig davon fände ich es sehr schlecht für die Usability wenn man inkompatible Erweiterungen gar nicht finden würde, das ist für die User ja deutlich verwirrender wenn es die Erweiterung auf extensions.contao.org gibt aber im Manager nicht. Für dein erwähntes Problem fände ich als Lösung einen Button für „Kompatibilität prüfen“ einen besseren Weg. Aber wie gesagt das gehört nicht in dieses Ticket finde ich.

[Metis77]

ja genau.
Composer macht einen super Job.
Und mir geht es hier weniger um composer, sondern eher darum dem User der sich vielleicht nicht so gut auskennt, Plugins nicht zur installation anzubieten, bei denen Klar ist, dass sie nicht installierbar sind. Also zB ein Plugin ^4.9 in einer Contao 5.3.* Installation.

Unabhängig davon fände ich es sehr schlecht für die Usability wenn man inkompatible Erweiterungen gar nicht finden würde,

Ja, das sehe ich auch so.
Es würde ja reichen, wenn man das Plugin zwar anzeigen würde an anstatt dem Button "Paket Hinzufügen" einfach einen Text "kompatibel mit: Contao 4"

[zonky2]

Für dein erwähntes Problem fände ich als Lösung einen Button für „Kompatibilität prüfen“ einen besseren Weg.

Unter Contao 3 mit dem alten ER gab es doch die Checkbox "Auch nicht kompatible Erweiterungen anzeigen" ... oder so ähnlich