Wechsel von composer nach composer-client

Hi,
habe gesehen, dass wohl umstrukturiert wurde.
Um nun von contao-community-alliance/composer 0.13.2 auf contao-community-alliance/composer-client 0.14 zu wechseln habe ich einfach nach contao-community-alliance/composer-client gesucht und installiert. Es wurde dann richtiger Weise die alte composer 0.13.2 ersetzt.

Automatisch wäre das nicht passiert, oder? Packagist zeigt das zwar an, "This package is abandoned .. using ...", aber die Verwaltung mach das wohl nicht automatisch mit, was ich verstehen kann.

Zitat:

---

Zitat von BugBuster

Automatisch wäre das nicht passiert, oder? Packagist zeigt das zwar an, "This package is abandoned .. using ...", aber die Verwaltung mach das wohl nicht automatisch mit, was ich verstehen kann.

---

Falsch, das wäre automatisch passiert, denn das Paket cca/composer-client ersetzt das Paket cca/composer, siehe https://packagist.org/packages/conta...omposer-client
Das wäre also früher oder später ohnehin aktualisiert worden ;)

Danke BugBuster,

das erklärt warum der Composer-Client bei meinen Installationen nicht mehr geupdated wurde. Hab die Umbenennung nicht mitbekommen.

Zitat:

---

Zitat von tril

Falsch, das wäre automatisch passiert, denn das Paket cca/composer-client ersetzt das Paket cca/composer, siehe https://packagist.org/packages/conta...omposer-client
Das wäre also früher oder später ohnehin aktualisiert worden ;)

---

Composer installiert mir also automatisch cca/composer-client auch wenn bei mir die Abhängigkeit auf cca/composer steht? Wann ist "früher oder später"?

In all meinen Installationen, die auf cca/composer gesetzt sind, nutzen diesen weiterhin und haben daher keine Updates mehr erfahren. Klar, wenn ich explizit composer-client installiere, geht es. Aber irgendwie nicht automatisch.

Die Client 0.14 gibt es seit 27 Tagen, ich glaube nicht dass es automatisch gekommen wäre, jedenfalls kam es bei meinen Installationen nicht.
Woher soll cca/composer auch wissen das es cca/composer-client gibt?

Ja, verstehe auch nicht wie das automatisch gehen soll. Wenn man ein Paket aus contao-legacy installiert hat, wofür es aber eigentlich ein Paket gibt, das dieses ersetzt, bekommt man ja auch nicht gleich automatisch das non-legacy Paket.

Aber einen Hinweis wie ich letztens bei mir gesehen habe, direkt darunter mit Pfeil. Ich wüsste jedenfalls nicht was dies sonst andeuten soll.
Anhang 14733
https://community.contao.org/de/atta...chmentid=14733

Bei mir sieht das jetzt so aus:
Anhang 14739

Ich kann aber auch beides nicht deinstallieren.
Stimmt das so... das wirkt irgendwie falsch...?

Bei einer anderen Installation hatte ich erst den
contao-legacy/composer v. 0.14
genommen, hab das "alte" Paket (0.13.2) entfernt.
Damit war dann die "Paketverwaltung" aus dem Contao Menü ganz verschwunden und ich musst den Composer per Backup reparieren.
Jetzt sieht das genauso aus.

edit:
Ok da gibts auch nen Ticket:
https://github.com/contao-community-...ent/issues/211
scheint so als würde der Eintrag neu erstellt statt umbenannt oder so, wenn man das aus der composer.json löscht ist es weg...

Zitat:

---

Zitat von BugBuster

Woher soll cca/composer auch wissen das es cca/composer-client gibt?

---

Weil es auf packagist.org eingetragen ist und cca/composer-client den cca/composer replaced!
https://github.com/contao-community-...poser.json#L43
https://getcomposer.org/doc/04-schema.md#replace

Zitat:

---

Zitat von BugBuster

Aber einen Hinweis wie ich letztens bei mir gesehen habe, direkt darunter mit Pfeil. Ich wüsste jedenfalls nicht was dies sonst andeuten soll.
Anhang 14733
https://community.contao.org/de/atta...chmentid=14733

---

Genau das ist so ein "replacement" eines Pakets, mit einer neuen Version.

Zitat:

---

Zitat von Znrl

Bei mir sieht das jetzt so aus:
Anhang 14739

Ich kann aber auch beides nicht deinstallieren.
Stimmt das so... das wirkt irgendwie falsch...?

---

Ja, das ist auch falsch, der Code für die Anzeige der Pakete ist mittlerweile so stark gewachsen und ich habe den drei mal umgeschrieben, dass ich aktuell selbst nicht mehr durchblick und es immer wieder vereinzelt zu Anzeigefehlern kommt. Auch wenn es bei dir darauf begründet war, dass du 2 Einträge in der composer.json hattest... :o

Zitat:

---

Zitat von tril

Weil es auf packagist.org eingetragen ist und cca/composer-client den cca/composer replaced!
https://github.com/contao-community-...poser.json#L43
https://getcomposer.org/doc/04-schema.md#replace

---

Ich hab zum Thema replace auch mal einen Artikel im Wiki geschrieben: http://de.contaowiki.org/Composer/Replace

Zitat:

---

Zitat von tril

Ich hab zum Thema replace auch mal einen Artikel im Wiki geschrieben: http://de.contaowiki.org/Composer/Replace

---

Danke für den Artikel. Wenn ich das richtig verstehe, kann quasi jeder vorgaukeln dass er ein bestimmtes Paket sei. Ich könnte also ein Package erstellen, dass den CCA Composer Client ersetzt. In etwas so:

Code:

---

{
    "takeover/composer-client",
    "version": "99.0",
    "replace": { "contao-community-alliance/composer-client": "*" }
}

---

Composer würde das akzeptieren und aufgrund der Versionsnummer auch bevorzugen (solange kein Constraint auf eine bestimmte Version, wie gesetzt ist ~1.0 ).

Ich sehe das als riesige Sicherheitslücke in der Architektur an. Jetzt müsste ich nur für eine Weile unbemerkt "takeover/composer-client" online haben und könnte alle auf Composer basierten Contao Installationen übernehmen, die ein update durchführen.

Soweit ich die von dir verlinkten Methoden überflogen habe, kann man Composer auch nicht dazu bringen das "orignal" zu benutzen.

Übersehe ich da irgendetwas oder ist es wirklich so einfach?

Zitat:

---

Zitat von webstar

Übersehe ich da irgendetwas oder ist es wirklich so einfach?

---

Es ist wirklich so einfach. Und nein, dass ist keine "Sicherheitslücke", diese Funktion hat jede und ich meine wirklich jede Paketverwaltungssoftware. Von apt, über rpm und yui bis npm und composer haben alle das gleiche "Problem".

Zitat:

---

Zitat von tril

Es ist wirklich so einfach. Und nein, dass ist keine "Sicherheitslücke", diese Funktion hat jede und ich meine wirklich jede Paketverwaltungssoftware. Von apt, über rpm und yui bis npm und composer haben alle das gleiche "Problem".

---

Ja, das composer damit nicht alleine dasteht, ist mir klar. :)

In Gegenzug zu beispielsweise apt, wo ich normalerweise erstmal nur die vertrauenswürdigen Pakete der Distribution drin habe, ist die Packagist-Repostory jedoch für alle offen. Es findet also vorab keine Auswahl statt.

Dies begingt eigentlich immer ein run-dry zu machen bevor man ein Update durchführt. Wäre schön, wenn das in einer zukünftigen Version auch so in das UI der Composer-Clients/Contao Paket Managers reinfließt.

Damit meine ich, dass man Standardmäßig erst einmal ein "Aktualisierungen ermitteln" ausführt. Dies erzeugt eine Übersicht der Änderungen, die durchgeführt werden. Erst hier wird ein "Pakete aktualisieren" angeboten. Natürlich mit einer Option "Aktualisierungen übermitteln überspringen", für alle, die wissen, was sie tun.

Aktuell wird im Composer Projekt (also nicht bei uns, sondern im eigentlich "composer" Projekt) an Lösungswegen für solche Fälle zu arbeiten. Bspw. durch Signierung u.ä.
Das ist imo der bessere Weg, als dem 0815 Nutzer ab zu verlangen zu unterscheiden ob das Update jetzt gut- oder bösartig ist. Das kann ja nicht mal ein Entwickler immer so ohne weiteres entscheiden :rolleyes:

Zitat:

---

Zitat von tril

Aktuell wird im Composer Projekt (also nicht bei uns, sondern im eigentlich "composer" Projekt) an Lösungswegen für solche Fälle zu arbeiten. Bspw. durch Signierung u.ä.
Das ist imo der bessere Weg, als dem 0815 Nutzer ab zu verlangen zu unterscheiden ob das Update jetzt gut- oder bösartig ist. Das kann ja nicht mal ein Entwickler immer so ohne weiteres entscheiden :rolleyes:

---

Wissen kann es es nie. Ich finde es nur empfehlenswert, dass einem auf irgendeiner Weise mitgeteilt wird, dass Pakete test nun nicht mehr test/test ist, sondern durch ein Äquivalent ersetzt werden wird. Ob nun wie bei dem Fall in diesem Thread composer durch composer-client oder halt durch einen anderen Anbieter.

Fraglich ist wie, weil bei einem DryRun würde da auch nur stehen:
- Uninstall cca/composer-client
- Install webstar/composer-client

Im schlimmsten Fall steht da aber sogar:
- Uninstall cca/composer-client
- Install bit3/irgendwas
- Upgrade metamodels/sonstwas
- Upgrade cca/composer-plugin
- Install isotope/shop
....
- Install webstar/composer-client

Da fehlt dann völlig der Zusammenhang und man weiß ggf. nicht was wie zusammen gehört.

Zitat:

---

Zitat von tril

Genau das ist so ein "replacement" eines Pakets, mit einer neuen Version.

---

Aber wann macht der Composer ein solches Replacement? Zumindest bei mir ist nichts automatisch passiert.

Mh, ich wollte es eigentlich gerade beweisen das es geht um dann festzustellen das Composer mir das Paket tatsächlich nicht ersetzt...
Ich schaue mir das später mal an, ich weiß noch nicht ob es an Composer selbst liegt (eventuell wurde auch was an Composer geändert) oder ob ich beim cca/composer-client irgendeinen Fehler gemacht habe :rolleyes:

Scheint tatsächlich geändert zu sein. Beründung und Details gibt es alle in folgenden Ticket:

https://github.com/composer/composer/issues/2690

@webstar danke für das nachschauen, das Ticket ist an mir vorbei gegangen. :o
Ich habe das Plugin in Version 2.3 veröffentlicht, das kümmert sich jetzt darum, dass auf cca/composer-client aktualisiert wird.

Hallo Tril,

Das automatische Ersetzen von contao-community-alliance/composer 0.13.2 mit contao-community-alliance/composer-client 0.14 schlägt leider fehl.
contao-core 3.3.7

Code:

---

32mLoading composer repositories with package information[39m
[32mUpdating dependencies
[37;41mYour requirements could not be resolved to an installable set of packages.[39;49m

  Problem 1
    - The requested package contao-community-alliance/composer-client could not be found in any version, there may be a typo in the package name.

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  for more details.

Read  for further common problems.

---

EDIT: Du hast als Constraint <14-dev drin stehen, es gibt aber keine Version <14 bei composer-client ;)

Das hab nicht ich eingetragen, sondern das passierte automatisch bei Click auf Pakete aktualisieren. Ich habe auch alle möglichen Composer-Einstellungen probiert, es bleibt immer dasselbe.

EDIT: Also nochmal:
Den Composerwechsel hatte ich nicht explizit angestoßen, sondern die Fehlermeldung erschien, weil ich Isotope aktualisieren wollte.
Ich konnte es jetzt aber, dank deiner Antwort, lösen, indem ich den composer-client 0.15 gezielt ausgewählte. Auch die Isotope-Aktualisierung lief darauhin problemlos durch.

Danke für die schnelle Hile.

Mh, dass musst du mal eingetragen haben (also die Constraint), dass wird von unserer Seite nie so voreingetragen.
Die Lösung ist aber ganz einfach, klicke auf das Paket, wähle die 0.14er Version aus und drücke auf "vormerken", dann kannst du aktualisieren.

Hi Tril,

siehe mein EDIT oben.
Ich habe definitiv nie etwas in dieser Hinsicht eingetragen.

Hallo Tril,

ich konnte die fehlerhafte Versionsanzeige in einer zweiten Installation reproduzieren. Siehe screenshot. Ab hier wird der falsche Constraint ausgegeben.
Und auch hier: An den Constraints wurde von mir nichts ver/geändert.

Ich schätze mal dass das beim upgrade von /composer auf /composer-client passiert.

Moin,

@Spooky das wäre theoretisch denkbar, aber beim composer-client gibt es nur eine Version 0.14 aufwärts, daher kann man die 0.13 gar nicht auswählen.
@bizon eigentlich wird von unserer Seite niemals eine so strikte Constraint eingerichtet, deshalb bin ich verwundert. Für deine betroffenen Installationen weißt du ja jetzt wie du das Update hin bekommst.

Ich habe aber noch eine neue Version 2.3.3 vom Plugin heute raus gehauen. Die prüft, ob die eingestellte Version auch ein Update auf >=0.14 erlauben würde und wenn nicht die Constraint gleich mit aktualisiert. Das hilft aber natürlich nur denjenigen, die jetzt noch nicht aktualisiert haben und in diesem "Dead-Lock" stecken.

Guten Morgen allerseits,

@tril
ich habe gestern einige Contao Updates auf 3.7 durchgeführt und diese Constrain Sache trat bei jeder Installtion auf. War dann aber, Dank deiner Hilfe, nicht weiter schlimm und alle upgrades liefen mit minimalstem manuellen Einsatz sauber durch.

Heute Morgen stand ein weiteres Update an und jetzt funktioniert es auch mit dem Constrain wie es soll. Der Constrain stand auf ~0.14 und der Umstieg Composer -> Composer-Cient wurde automatisch auf 0.15 durchgeführt - also alles perfekt.

Bei der Gelegenheit möchte ich dir und deinem Team herzlich für eure hervorragende Arbeit danken. Ich nutze Composer und Theme+ in ca. 15 Installationen und bin total happy, dass Composer meine websites so schnell auf den neuesten Stand bringt.

LG bizon