Composer dazu zwingen, eine PHP-Version zwischen Version X und Version Y anzufordern

Lesezeit: 1 Minute

Wir haben eine Mischung aus verschiedenen PHP-Versionen, die auf Ihren Servern (max. 5.3.5) und Entwicklungsmaschinen (max. 5.5.9) laufen.

Jetzt sind wir auf das Problem gestoßen, dass wir ein “Composer-Update” durchgeführt haben, um die neueste Version einiger externer Bundles zu erhalten. Da Ihre composer.json aussieht

"require": {
        "php": ">=5.3.3",
        .....
    },

Wir erhalten einige Bundles, die PHP 5.5 erforderten. Kein Problem auf unseren Entwicklungsmaschinen, aber auf dem Server 🙁

Gibt es eine Möglichkeit, Composer anzuweisen, eine PHP-Version zwischen 5.3.3 und 5.3.5 zu benötigen? Oder eine maximal verfügbare Version?

Ich habe es versucht

"require": {
        "php": ">=5.3.3, <=5.3.5",
            .....
        },

und

"require": {
            "php": "<=5.3.5",
                .....
            },

aber beides ging nicht. Ich erhalte die Meldung “Das angeforderte PHP-Paket konnte in keiner Version gefunden werden, möglicherweise enthält der Paketname einen Tippfehler.” Fehler.

Irgendwelche Ideen? Danke im Voraus

Da der Konfigurationsparameter in composer.json verfügbar ist. Du könntest so etwas:

{
    "name": ".../...",
    "config": {
        "platform": {
            "php": "5.3.5"
        }
    },
    "require": {
        ...
    }
} 

https://getcomposer.org/doc/06-config.md#platform

  • Obwohl dieser Parameter angegeben ist, installiert die Bibliothek dennoch eine Version, die größer ist als die angegebene PHP-Version. Zum Beispiel habe ich PHP Version 5.4.36 angegeben, aber Composer installiert immer noch Symfony Version 3.1.3, was 5.5+ erfordert. Fazit: Funktioniert nicht.

    – Raubvogel

    9. August 2016 um 4:42 Uhr

  • Plattform dient hauptsächlich dazu, Plattformpakete (PHP und Erweiterungen) zu fälschen, damit Sie eine Produktionsumgebung emulieren können. require ist die bessere Wahl zwischen Version X und Version Y

    – Walt Sörensen

    3. Februar 2017 um 7:02 Uhr

  • Das hat bei mir gut funktioniert! Ich musste Pakete installieren, die mit PHP <=7.0.16 kompatibel sind

    – Aktienbruch

    31. Juli 2017 um 14:11 Uhr

  • Vielleicht gab es irgendwo in der Kette einen Fehler für Raptor, aber config.platform.php soll genau das Problem in dieser Frage lösen, und es funktioniert. Möglicherweise hat die verwendete Composer-Version dies noch nicht unterstützt.

    – Narretz

    14. November 2017 um 13:10 Uhr


  • Genau was ich gesucht habe, danke! Wichtig zu beachten, dass Sie laufen müssen composer update nachdem Sie dies festgelegt haben, genau wie jede andere abhängigkeitsbezogene Änderung an composer.json.

    – Evan Mattson

    30. Mai 2018 um 15:55 Uhr

Benutzer-Avatar
Sven

Ich finde es gelinde gesagt fragwürdig, dass Sie mit dem neuesten verfügbaren PHP entwickeln und die Produktion mit einer sehr veralteten Version betreiben. Daraus ergeben sich viele mögliche Probleme, nicht nur wegen fehlender Sicherheitspatches, sondern vor allem wegen PHP-Fehlerbehebungen, die hauptsächlich in den Versionen 5.3.9 und 5.3.23 eingeführt wurden und das PHP-Verhalten in einigen ändern Details ziemlich grundlegend. Ganz zu schweigen von dem Risiko, versehentlich Funktionen von 5.4 oder 5.5 zu verwenden.

Und es gibt wirklich keine Möglichkeit, Composer dazu zu bringen, mit dieser Situation fertig zu werden. Die PHP-Version, die beim Ausführen verwendet wird composer update bestimmt die Auflösung von Abhängigkeiten, beeinflusst von der PHP-Version und installierten PHP-Erweiterungen.

Sie können nicht festlegen, dass ein Paket nur für PHP-Versionen zwischen 5.3.3 und 5.3.5 verwendet werden soll, wenn das PHP, das Sie für das Update verwenden, diese Versionsanforderung nicht erfüllt. Da die verwendete PHP-Version die obere Versionsbeschränkung überschreitet, ist ein solches Paket nicht geeignet, die Versionsanforderung zu erfüllen, und Composer meldet, dass kein Paket gefunden wurde (sagt nicht, dass er die Pakete gesehen hat, sie aber wegen ignoriert werden mussten die Versionsbeschränkung).

Es gibt wahrscheinlich drei offensichtliche Auswege:

  1. Führen Sie ein Downgrade Ihrer Entwicklungsumgebung auf die Produktionsversion durch, die Sie wirklich verwenden. Wenn mehr als eine verwendet wird: Die älteste. Auf diese Weise werden alle Anforderungen an PHP-Versionen angepasst. Laufen composer update dann, und du bist fertig.

  2. Rüsten Sie Ihre Produktionsumgebung auf. Braucht keine weitere Erklärung, aber ich muss erwähnen, dass Ihnen nicht nur viele sehr schöne PHP-Features fehlen, sondern auch eine erhebliche Leistungssteigerung, denn PHP 5.5 ist wirklich so viel schneller als 5.3.

  3. Fügen Sie eine „platform.php“-Konfiguration entweder der Datei „composer.json“ des globalen oder des Projekts hinzu. Dadurch wird Composer angewiesen, die PHP-Version, auf der Composer selbst ausgeführt wird, zu überschreiben und stattdessen die Abhängigkeiten mit dieser anderen PHP-Version zu berechnen. composer config -g platform.php 5.3.5 für globale Einstellung (wirkt sich auf alle weiteren Composer-Läufe aus), ohne -g für lokale Einstellung (wirkt sich nur auf Composer-Operationen in diesem Projekt aus, falls Sie an mehr als einem Projekt mit unterschiedlichen Produktionsversionen von PHP entwickeln).

  • Ich habe eine neue dritte Option hinzugefügt, die für neuere Versionen von Composer gültig sein sollte, wahrscheinlich ab 1.0.0-beta1 und höher (ich werde jetzt nicht in die Alpha-Release-Notes graben, um es Ihnen genau zu sagen). Verwenden Sie einfach die stabile Version 1.0.0.

    – Sven

    15. April 2016 um 0:33 Uhr

  • @Arcesilas Was meinst du? Die Frage ist im Grunde, wie Composer darauf beschränkt werden kann, Pakete für zu fortgeschrittene Versionen von PHP auszuwählen während eines Updates – daher ist die Sperrdatei, obwohl sie das Ergebnis eines Updates beeinflusst, in diesem Zusammenhang bedeutungslos.

    – Sven

    4. Dezember 2017 um 17:07 Uhr

  • Menschen haben Zwänge… gar nicht so fragwürdig, oder?

    – Raulsson

    17. Mai 2018 um 20:05 Uhr

  • Es ist fragwürdig, in Entwicklung und Produktion nicht die gleichen Versionen zu verwenden. Fehler können sich leicht einschleichen, wie die Verwendung einer PHP-Funktion, die die Produktion nicht hat, oder ein Fehler, der in DEV behoben wurde, aber in der Produktion immer noch nicht behoben ist. Wenn Sie nicht dieselbe Version verwenden, bedeutet dies, dass Sie nicht dasselbe Verhalten feststellen werden. Besonders beim Mischen von PHP 5.3 in prod mit PHP 5.5 in dev (Probleme sind weniger wahrscheinlich oder überraschend, wenn 5.5.x mit 5.5.y gemischt werden).

    – Sven

    18. Mai 2018 um 9:23 Uhr


  • Hallo Sven, das machen wir auch. Entwickeln in einer höheren Version, die wir dann in Produktion haben. Der Grund ist: dass unser Code zukunftsfähig ist. Wenn wir also ein Upgrade durchführen müssen, müssen wir uns keine großen Sorgen machen, da es bereits getestet wurde. Wir sind Plain-Vanilla-Entwickler ohne PHP-Unit etc., weil das noch nicht existierte, als unser Framework zum Leben erweckt wurde. Wir haben also andere Möglichkeiten, unseren Code zu überwachen und zu testen.

    – flexJoly

    6. Februar 2020 um 11:19 Uhr

Versuchen Sie dies (Komma entfernen):

"require": {
    "php": ">=5.3.3 <=5.3.5",
        .....
    },

Benutzer-Avatar
sh6210

Entfernen Sie Ihre komponist.lock und Verkäufer Verzeichnis.

Jetzt platzieren Plattform Option zu composer.json

"config": {

    "platform": {
        "php": "7.0"
    }

},

und schließlich Befehl ausführen Composer installieren

Wie wäre es mit dem Tilde-Operator?

Tilde-Operator ~1.2 Sehr nützlich für Projekte, die semantischer Versionierung folgen. ~1,2 entspricht >=1,2,<2,0. Weitere Einzelheiten finden Sie im nächsten Abschnitt unten.

Nächste bedeutende Veröffentlichung (Tilde-Operator)#

Der Operator ~ lässt sich am besten anhand eines Beispiels erklären: ~1.2 ist äquivalent zu

=1.2,<2.0, während ~1.2.3 äquivalent zu >=1.2.3,<1.3 ist. Wie Sie sehen können, ist es vor allem für Projekte nützlich, die semantische Versionierung berücksichtigen. Eine übliche Verwendung wäre, die minimale Nebenversion zu markieren, von der Sie abhängen, wie etwa ~1.2 (was alles bis zu, aber nicht einschließlich, 2.0 zulässt). Da es theoretisch bis 2.0 keine Abwärtskompatibilitätsbrüche geben sollte, funktioniert das gut. Eine andere Sichtweise ist, dass die Verwendung von ~ eine Mindestversion angibt, aber erlaubt, dass die letzte angegebene Ziffer nach oben geht.

Hinweis: Obwohl 2.0-beta.1 strikt vor 2.0 liegt, würde eine Versionseinschränkung wie ~1.2 es nicht installieren. Wie oben gesagt bedeutet ~1.2 nur, dass sich die .2 ändern kann, aber der 1. Teil ist fest.

Hinweis: Der ~-Operator hat eine Ausnahme bezüglich seines Verhaltens für die Hauptversionsnummer. Dies bedeutet zum Beispiel, dass ~1 dasselbe wie ~1.0 ist, da es nicht zulässt, dass die Major-Nummer erhöht wird, um die Abwärtskompatibilität aufrechtzuerhalten.

Gibt es eine Möglichkeit, Composer anzuweisen, eine PHP-Version zwischen 5.3.3 und 5.3.5 zu benötigen?

Ja, da ist es einer:

Versionsbereich mit Bindestrich ( – )

Inklusive Satz von Versionen. Teilversionen auf der rechten Seite werden mit einem Platzhalter abgeschlossen. Zum Beispiel entspricht 1.0 – 2.0 >=1.0.0 <2.1, da 2.0 zu 2.0 wird.*. Andererseits entspricht 1.0.0 - 2.1.0 >=1.0.0 <=2.1.0.

Beispiel: 1,0 – 2,0

https://getcomposer.org/doc/articles/versions.md#hyphenated-version-range-

oder Sie können verwenden composer.json so was:

{
  "require": {
    "guzzlehttp/guzzle": ">=5.3.4 <6"
  }
}

– Ich persönlich bevorzuge diesen Weg, weil es IMHO viel einfacher zu lesen und zu merken ist.

1345520cookie-checkComposer dazu zwingen, eine PHP-Version zwischen Version X und Version Y anzufordern

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy