Composer blockiert Updates/installation von Modulen wegen einer Erweiterung?

[Kahmoon]

Tach beisammen,

mein spezieller Freund Composer macht mir gerade wieder das Leben schwer. Ich musste eine Installation auf Composer umstellen und kann jetzt (vermutlich) wegen einer Erweiterung andere Erweiterungen weder installieren noch updaten. Auch wenn ich das betroffene Modul sperre, macht er nicht weiter. Es kommt nur folgende Meldung:

Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

Problem 1
- Installation request for felixpfeiffer/contao-simple-event-registration >=3.2.4.0,<3.3-dev -> satisfiable by felixpfeiffer/contao-simple-event-registration[3.2.4].
- felixpfeiffer/contao-simple-event-registration 3.2.4 requires contao-community-alliance/composer-installer ~2.0 -> no matching package found.

Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting
see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.

Read <http://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.

Was kann ich hier machen? Ich verstehe auch nicht warum die Erweiterung 2 mal aufgelistet ist (siehe Anhang).

Ich habe auch versucht eine neue Erweiterung (cameraslideshow legacy) von Hand zu installieren aber er zeigt beim Datenbankupdate nichts an...somit bekomme ich das Modul nicht zum laufen

VG

[xtra]

Er zeigt sie nur einmal an, jedoch ist die "contao-legacy" Variante die "alte" und wurde durch die andere abgeloest (siehe den grynen Kasten).
Selbiges auch bei "contao-legacy/botdetection", welche durch "bugbuster/botdetection" abgeloest wurde.
Klicke also auf die grynen Kaesten und waehle die korrekte Version aus, anschliessend kannst du bei den "contao-legacy" varianten den "delete" button verwenden, da ja die "neue" Version verwendet werden soll.
Damit hast du schon mal ein "sauberes upgrade".

Bzgl. deines Problems dann: "felixpfeiffer/contao-simple-event-registration" moechte das Package "contao-community-alliance/composer-installer" in Version "2.0" oder neuer haben, dieses gibt es jedoch nicht. Das korrekte Package waere "contao-community-alliance/composer-plugin" in Version "2.0".
Du musst also ein Ticket bei "felixpfeiffer/contao-simple-event-registration" machen, damit es dort korrigiert wird.

[Kahmoon]

Danke für die Erklärung

Ich habe jetzt ein Update von Composer gemacht, die Erweiterung von Felix Pfeifer gelöscht (aber nicht die Datenbank aktualisiert) und anschließend neu installiert. Jetzt funktioniert wieder alles und es steht auch nur ein mal drin.

Man sieht bei Composer aber nach wie vor nicht ob es ein Update einer Erweiterung gibt oder?

[Spooky]

Nein (noch) nicht. Das siehst du nur wenn du ein Update machst (oder einen Dry run bspw.).

[Kahmoon]

Also Testlauf ohne ein Häkchen würde dann alle vorhandenen durchgehen und dann im Log anzeigen was er updaten würde?

[Spooky]

Was für ein Häkchen? Aber ja, wenn du auf "Testlauf/Dry run" klickst, siehst du, was Composer alles machen würde.

[Kahmoon]

Häkchen vor den Modulen um z.B. den Testlauf nur ein ein Modul zu fahren?

[Spooky]

Ah, ist das neu? kA

[felixpfeiffer]

Habe die composer.json in der Simple Event Registration nun angepasst. Sorry für den Fehler.

[Znrl]

Die Häkchen beziehen sich nur auf das "Ausgewählte Pakete entfernen".

Updaten kannst du nur alles zusammen.
Auch das Sperren ändern das meine ich nicht, es wird dann eben ein passendes "gesamt Update" gesucht, bei dem das gesperrte (auf die Version verankerte) Modul nicht geupdated werden muss.
Das heißt potentiell wird bspw. ein anders Modul nur bis zu der Version geupdatet, mit der es noch mit dem verankerten funktioniert.

[Webstylerin]

Ich habe bisher wenige Installationen mit dem Composer (was ich gerade sehr gut finde!) habe aber gerade dasselbe Problem "erwischt".

Im aktuellen Fall habe ich von Contao 3.3.7 auf die 3.5.0 upgedatet und die Erweiterungen sofern verfügbar in die Composer-Varianten umgewandelt. Nun wollte ich eine neue Erweiterung installieren und er meckert nur, dass "dma_elementgernerator" nicht in der nötigen Version gefunden wurde? Ja, die Erweiterung ist noch nicht für die 3.5 freigegeben, aber sie funktioniert bei mir in mehreren 3.5er Versionen (mit der alten Erweiterungsverwaltung), daher hab ich mir da keine Gedanken gemacht.
Composer-Meldung: Bildschirmfoto 2015-07-21 um 11.24.10.png
Habe auch das Update des Elementgenerators gesperrt, er meckert trotzdem fröhlich weiter.

Kann es wirklich sein, dass eine Erweiterung, die nicht zu meiner aktuellen Contao-Version passt alles blockert? Funktionieren jetzt auch die Updates der Erweiterungen nicht, solange der Elementgenerator nicht für die 3.5 freigegeben ist? Kann ich das irgendwie umgehen?

Es gibt immer mal Erweiterungen deren Version nicht mehr angepasst wird. Am Beispiel von Contao 3.2 sehe ich, dass viele Erweiterungen nur noch "voraussichtlich" kompatibel sind, weil die Entwickler eben nicht mehr auf die neuste Version hochziehen, da steht dann halt noch die 3.2.19 drin statt der 3.2.21. Muss ich mit dem Composer mit dem Contao-Update jetzt immer warten bis alle Entwickler nachgezogen sind?

So, jetzt hab ich die Composer-Version deinstalliert und die Legacy-Version des dma_elementgenerators installiert. Das wird aber nicht bei allen Erweiterungen klappen.

Leicht verzweifelte Grüße
Nicole

[xtra]

Geaendert wurde es schon mit folgendem Commit. https://github.com/DMAGmbH/dma_eleme...a340cb65c572ae

Janosch hat ihn leider noch nicht getagged, weshalb du damit dann den dma/elementgenerator in der Version "dev-master" requiren musst.
Leider hat er auch keinen branch-alias, weshalb du nicht einmal "2.0@dev" oder so nehmen kannst.

Und nein, so einfach kann man das nicht umgehen, das ist ja gerade der ganze Sinn hinter dem composer, dass sowas eben NICHT mehr passiert.
Wenn der Entwickler sagt (oder gesagt bekommt, wie in obigem Fall wo der commit als PR von Kirsten kam) dass es kompatibel ist, dann ist es kompatibel, ansonsten eben nicht.

[Spooky]

Aus der Sicht des Content Management Systems ist es schon ein wenig ungemütlich, dass nach einem Update des CMS plötzlich gar keine Extensions mehr aktualisiert werden können, wenn eine nicht mehr kompatibel ist. Ich weiß, dass Composer hier keine anderen Möglichkeiten bietet, aber ich kann den Unmut darüber nachvollziehen. Hier bleibt einem nur über die Extension temporär zu entfernen und ggf. manuell zu installieren (was bei Extensions mit mehreren, verschachtelten Abhängigkeiten wohl fast unmöglich ist).

[xtra]

Nunja, normalerweise hat man auch einen stabilen Stand, welcher installiert wurde.

hier wurde jedoch das Grundsystem "drumrum" aktualisiert BEVOR die Extensions zur Neuen Version kompatibel sind.
Von daher gesehen hat man hier schon von Hand die Abhaengigkeiten zerstoert was jedoch nicht Composer anzulasten ist.

Ein allgemeines Update geht tadellos, sobald ein Upgradepfad existiert. Hierbei werden neue, noch nicht kompatible, Versionen einfach ausgelassen.

Der Unmut ist also nur bedingt zu verstehen, weil die Leute es vom ER2 leider einfach "falsch" gewohnt sind.

[Spooky]

hier wurde jedoch das Grundsystem "drumrum" aktualisiert BEVOR die Extensions zur Neuen Version kompatibel sind.
Von daher gesehen hat man hier schon von Hand die Abhaengigkeiten zerstoert was jedoch nicht Composer anzulasten ist.

Ja stimmt auch wieder. Allerdings ist es derzeit noch etwas mühsam herauszufinden, welche Extensions schon mit höheren Contao Versionen kompatibel sind und welche nicht. Derzeit kann man eigentlich nur mühsam die Repositories durchkämmen und die composer.json in einen oder mehreren branches oder releases selbst analysieren, oder?

[tab]

Rein technisch stimme ich da xtra voll zu, dem Composer kann man es nicht anlasten, wenn er keine Veränderungen durchführen kann, solange der aktuelle Stand selbst gar nicht konsistent ist. Würde er das tun, wäre es ein schlechtes Programm. Dass das gute alte ER2 das problemlos (?) macht, ist natürlich genauso zu bewerten.

Ich finde aber die augenblickliche Situation einigermaßen unglücklich. Man KANN Contao 3.x ja schliesslich nicht über Composer updaten, es geht also eigentlich nur drum herum. Wie geht man eigentlich korrekt vor, wenn man - wie Kirsten im vorliegenden Fall - den Entwickler unterstützen will, indem man einfach testet, ob die Erweiterung kompatibel ist oder nicht? Der Composer lässt sie einen ja - formal korrekt - gar nicht erst installieren, oder sehe ich das falsch? Also manuelle Installation?

Oder gibt es einen Mechanismus, mit dem ich Composer klarmachen kann: Installiere das, auch wenn es auf dem Papier nicht kompatibel ist. Kann ich es also irgendwie formal für kompatibel erklären, also Composer sagen: Diese Erweiterung ist kompatibel zu Contao 3.5, auch wenn sie selbst was anderes behauptet? In der .json Datei oder wo auch immer? Also eine Art Testmodus für eine Erweiterung. Oder, falls das einfacher zu machen ist, eine Checkbox der Art: Kompatibilitätsüberprüfung abschalten, ich übernehme die volle Verantwortung . Dass man dabei - wie immer selbstverständlich - vorher ein komplettes Backup machen sollte, sollte eh klar sein.

Man ist sonst eben noch ein Stück mehr vom Entwickler abhängig als bisher beim ER2. Da konnte man so eine vermeintliche - oder auch echte - Inkompatibilität einfach willentlich ignorieren. Z.B. wenn man aus eigener Erfahrung oder durch Berichte anderer wusste, dass die Erweiterung kompatibel ist, auch wenn der Entwickler sie noch nicht freigegeben hatte. Oder um eben genau das erst einmal zu testen. Erst mal ohne Composer zu testen ist ja leider mittlerweile auch fast nicht mehr praktikabel, weil man dazu manche Erweiterungen mit teilweise unzähligen Abhängigkeiten manuell installieren müsste, da sie nicht mehr übers ER2 installierbar sind.

[xtra]

Die "einfachste" und auch empfohlene Vorgehensweise ist, dass man das repository forked, einen branch alias anlegt (sofern noch nicht vom Entwickler entsprechend passiert), dann das repository in seiner composer.json notiert und die composer.json im repository entsprechend abaendert.
Damit kann es dann installiert werden.
Das ist logischerweise nur praktikabel, wenn man wirklich an der Extension entwickeln moechte/Kompatibilitaet herstellen moechte.
Lieschen Myller wird das sicher nicht machen und soll sie auch gar nicht... A. L. User auch nicht. Dadurch sind sie schon von vornherein geschytzt dass sie sich nichts kaputt machen.

P.S.: Hinsichtlich der Kompatibilitaet tut sich aktuell einiges. Immer mehr Entwickler setzen auch unit tests und tools wie travis, dadurch werden sich die Releasezeitraeume sicherlich drastisch verringern.
P.P.S.: durch diese schnelleren Releasezyklen werden dann bald alle, die jammern dass Extensions zu lange brauchen bis sie kompatibel sind, jammern dass zu schnell und zu viele Releases kommen und sie mit dem updaten nicht hinterher kommen.

[tab]

Dein Wort in Gottes Gehörgang .

Edit: Und danke für die Skizzierung der empfohlenen Vorgehensweise.

[Spooky]

Die "einfachste" und auch empfohlene Vorgehensweise ist, dass man das repository forked, einen branch alias anlegt (sofern noch nicht vom Entwickler entsprechend passiert), dann das repository in seiner composer.json notiert und die composer.json im repository entsprechend abaendert.
Damit kann es dann installiert werden.
Das ist logischerweise nur praktikabel, wenn man wirklich an der Extension entwickeln moechte/Kompatibilitaet herstellen moechte.
Lieschen Myller wird das sicher nicht machen und soll sie auch gar nicht... A. L. User auch nicht. Dadurch sind sie schon von vornherein geschytzt dass sie sich nichts kaputt machen.

P.S.: Hinsichtlich der Kompatibilitaet tut sich aktuell einiges. Immer mehr Entwickler setzen auch unit tests und tools wie travis, dadurch werden sich die Releasezeitraeume sicherlich drastisch verringern.
P.P.S.: durch diese schnelleren Releasezyklen werden dann bald alle, die jammern dass Extensions zu lange brauchen bis sie kompatibel sind, jammern dass zu schnell und zu viele Releases kommen und sie mit dem updaten nicht hinterher kommen.

All das wird aber nichts daran ändern, dass man aktuell vor einem Contao Update nicht schnell herausfinden kann, ob danach alle Erweiterungen überhaupt noch kompatibel sind (und im Zuge dessen auch andere Erweiterungen aktualisiert werden können).

[Webstylerin]

Hallo zusammen,

danke für eure Antworten, ihr habt durch aus etwas Licht in die Composer-Sache gebracht.

Geaendert wurde es schon mit folgendem Commit. https://github.com/DMAGmbH/dma_eleme...a340cb65c572ae

Janosch hat ihn leider noch nicht getagged, weshalb du damit dann den dma/elementgenerator in der Version "dev-master" requiren musst.
Leider hat er auch keinen branch-alias, weshalb du nicht einmal "2.0@dev" oder so nehmen kannst.

Und nein, so einfach kann man das nicht umgehen, das ist ja gerade der ganze Sinn hinter dem composer, dass sowas eben NICHT mehr passiert.
Wenn der Entwickler sagt (oder gesagt bekommt, wie in obigem Fall wo der commit als PR von Kirsten kam) dass es kompatibel ist, dann ist es kompatibel, ansonsten eben nicht.

Genau deswegen macht mir die Sache mit dem Composer etwas Bauchschmerzen. Das Commit ist seit über einem Monat offen und nichts hat sich getan. Mir ist durch aus bewusst, dass ich einem Entwickler der seine Arbeit kostenlos zur Verfügung stellt hier nichts sagen darf, aber es ist halt für mich als Nutzer dann schon etwas doof wenn ich deswegen auf mein Contao-Update verzichten muss.

hier wurde jedoch das Grundsystem "drumrum" aktualisiert BEVOR die Extensions zur Neuen Version kompatibel sind.
Von daher gesehen hat man hier schon von Hand die Abhaengigkeiten zerstoert was jedoch nicht Composer anzulasten ist.

Ja, weil ich von den ER2-Installationen wusste, dass der Elementgenerator funktioniert. Ich wusste zwar, dass der Composer sich um "Abhängigkeiten" kümmert, aber das deswegen nichts mehr geht, wusste ich nicht.

Der Unmut ist also nur bedingt zu verstehen, weil die Leute es vom ER2 leider einfach "falsch" gewohnt sind.

Ja, da bin ich wohl ein verwöhntes Gör und mich mich daran gewöhnen, auch mal ein "Nein" zu hören.

Die "einfachste" und auch empfohlene Vorgehensweise ist, dass man das repository forked, einen branch alias anlegt (sofern noch nicht vom Entwickler entsprechend passiert), dann das repository in seiner composer.json notiert und die composer.json im repository entsprechend abaendert.
Damit kann es dann installiert werden.
Das ist logischerweise nur praktikabel, wenn man wirklich an der Extension entwickeln moechte/Kompatibilitaet herstellen moechte.
Lieschen Myller wird das sicher nicht machen und soll sie auch gar nicht... A. L. User auch nicht. Dadurch sind sie schon von vornherein geschytzt dass sie sich nichts kaputt machen.

Ich oute mich dann mal als Lieschen und lass das die Entwickler machen die sich damit auskennen. Nächstes mal also GENAU PRÜFEN ob alle Erweiterungen schon umgestellt sind.

All das wird aber nichts daran ändern, dass man aktuell vor einem Contao Update nicht schnell herausfinden kann, ob danach alle Erweiterungen überhaupt noch kompatibel sind (und im Zuge dessen auch andere Erweiterungen aktualisiert werden können).

Das ist natürlich sehr schade. Gibt es schon irgendwelche Pläne hier etwas zu ändern?

Sommerliche Grüße
Nicole