Composer – Das angeforderte Paket existiert als, aber diese werden von Ihrer Einschränkung abgelehnt
Lesezeit: 4 Minuten
Antoine Bourlart
Wenn ich meine Installation von Composer ausführe, habe ich diesen Fehler:
λ Composer-Installation Sie führen Composer mit aktiviertem xdebug aus. Dies hat einen großen Einfluss auf die Laufzeitleistung. Sehen https://getcomposer.org/xdebug
Laden von Composer-Repositories mit Paketinformationen Aktualisieren von Abhängigkeiten (einschließlich require-dev) Ihre Anforderungen konnten nicht in einen installierbaren Satz von Paketen aufgelöst werden.
Fehler :
Problem 1 – Das angeforderte Paket antoineb1/smoney_bundle 1.0 existiert als antoineb1/smoney_bundle[dev-master] aber diese werden von Ihrer Einschränkung abgelehnt.
Die Versionsbeschränkung "1.0" ist intern interpretiert wie "1.0.0.0-stable" Ausführung.
Aber die einzige verfügbare Version ist:
antoineb1/smoney_bundle[dev-master].
Sie können also die angegebene Version in eine der folgenden ändern, je nachdem, welche Version für Sie geeignet ist:
1.0.* (was vom Komponisten als angesehen wird >=1.0.0.0-dev <1.1.0.0-dev — wird wahrscheinlich nicht funktionieren, da es offensichtlich keine Versionen in diesem Paket gibt)
Ich habe das gleiche Problem. Ich habe ein Tag 1.1.0 in meinem Repo verfügbar, aber der Komponist sagt immer noch, dass ich nur eine Dev-Master-Version habe, was nicht einmal wahr ist, ich habe keinen Zweig oder Tag mit diesem Namen …?!?
– Guillaume Bois
17. Januar 2017 um 19:50 Uhr
@GuillaumeBois Composer ermöglicht die Verwendung von Zweigen als Versionen, indem sie als angegeben werden dev-<branchname>Also dev-master bezieht sich auf master Zweig. Wenn Sie ein bestimmtes Tag angeben möchten, geht es wie folgt "author/package": "dev-master#v1.1.0". Siehe diese Frage für Details.
– BVengerov
18. Januar 2017 um 5:55 Uhr
Das Problem war, dass mein Tag war 1.1.0 und hätte sein sollen v1.1.0 ! OMG ich hasse die Computer…
– Guillaume Bois
19. Januar 2017 um 12:59 Uhr
Ich hatte dieses Problem, weil ich es versäumt hatte, mein Tag auf die Fernbedienung zu schieben. Es lohnt sich wahrscheinlich auch, Composer clear-cache auszuführen.
– Russ
23. August 2017 um 9:57 Uhr
Für mich, wenn “5.8. *” in composer.json eingestellt ist, wird immer 5.8.0 abgerufen, obwohl in meinem Remote-Repo ein 5.8.1-Tag vorhanden ist … Irgendwelche Ideen? 😮 Aber wenn ich 5.8.1 direkt einfüge, bekomme ich eine Fehlermeldung: Problem 1 – Das angeforderte Paket myrepo/advanced-custom-fields-pro v5.8.1 existiert als myrepo/advanced-custom-fields-pro[v5.8.0] aber diese werden von Ihrer Einschränkung abgelehnt. Jede Hilfe geschätzt.
– Zugoase
14. Juni 2019 um 12:12 Uhr
Der Kommentar von @Guillaume unter dieser Antwort verdient eine größere Darstellung.
Es scheint, dass der Komponist a will git-Freigabe das hat ein v drin.
So sollte es sein v1.1.0 und nicht 1.1.0.
Ich verbrachte ungefähr 90 Minuten damit, es mir anzusehen
mikeill/my_repo 3.3.10 requires composer/installers 1.0.*@dev -> satisfiable by composer/installers[1.0.x-dev, v1.0.0, ...] but these conflict with your requirements or minimum-stability.
Und viele Github-Probleme sowie ein oder zwei SO-Posts, bevor ich diesen Thread endlich entdeckte.
Trivial, aber leicht zu übersehen
– i_v_harisch
3. Oktober 2018 um 13:32 Uhr
Es scheint, dass mit der v Präfix ist die Art und Weise, wie die “Erwachsenen” es tun.
– MikeiLL
17. Juni 2020 um 15:43 Uhr
Ich habe eine Zeit lang viel Haar, Zeit und Verstand über diese Frage verloren – es stellte sich heraus, dass das Problem in meinem Fall darin bestand, dass ich eine Version in der composer.json innerhalb des Pakets selbst als “dev-master” angab.
Hinweis: Packagist verwendet VCS-Repositories, daher gilt die obige Aussage auch für Packagist. Wenn Sie die Version selbst angeben, wird dies höchstwahrscheinlich irgendwann zu Problemen führen aufgrund menschlichen Versagens.
(Hervorhebung von mir)
Ich habe dieses Versionselement entfernt und es hat perfekt funktioniert 🙂
Wo hast du das Versionselement entfernt? Ich habe keine und dies geschieht für ein privates Bitbucket-Repo
– Zugoase
14. Juni 2019 um 12:06 Uhr
Sie haben Recht, die andere Lösung besteht darin, die Version in Ihrem Repo mit der richtigen Versionsnummer zu kennzeichnen, und es würde auch funktionieren
– Mohamed Saleh
27. Juli 2020 um 21:37 Uhr
Ich bin auf diese Frage gestoßen und habe ein anderes Problem gefunden, das ich völlig vergessen hatte und das jemand möglicherweise überprüfen muss.
In meinem Fall hatte ich ein sehr altes Git-Projekt, das vor einiger Zeit geforkt worden war, und ich musste sie zusammenführen (obwohl das geforkte Projekt nicht viele Änderungen hatte). Also identifizierte ich den Split-Punkt im alten Projekt und markierte ihn als Version für Composer, damit ich diesen anstelle des neuen Projekts verwenden konnte.
Was ich jedoch vergessen hatte, war, dass wir ursprünglich keinen Composer benutzten. In der Dateistruktur am Tag-Punkt fehlte daher composer.json. Ich konnte nicht herausfinden, warum meine neuen Tags nicht auf der „existiert als“-Liste der Dinge erschienen, die „von Ihrer Einschränkung abgelehnt“ wurden. Irgendwann wurde mir klar, dass ich einen Zweig auf dem alten Tag erstellen, den Commit, der die composer.json für das Projekt erstellt hat, aussuchen und neu taggen musste, und dann hat alles funktioniert.
Hoffentlich wird dies jemandem in Erinnerung bleiben, wenn er mit dieser Fehlermeldung im Hinterkopf auf die Jagd kommt.
Nachdem ich eine Weile gesucht hatte, fand ich heraus, dass das Repository in meiner Composer-Datei fehlte. Jemand hat es entfernt, daher funktionierten nur frühere Versionen.