Libraries per Composer dynamisch laden

Hallo,

Quote from MysteryCode

Was mir durch das ein oder andere Paket immer wieder auffällt ist, dass man aktuell das ein oder andere Composer-Paket doppelt und dreifach im WSC hat, weil man es aktuell via Paket mitliefern muss.

beziehst du dich hier auf Duplikate zwischen eigenem Paket und WoltLab Suite Core (bspw. die PSR-Interfaces oder Guzzle) oder Duplikate zwischen separaten Third-Party-Paketen (bspw. DomPDF)?

Hallo,

Quote from MysteryCode

Guzzle und PSR waren jetzt auch die ersten Baustellen, an die ich gedacht habe.

das kannst du verhältnismäßig einfach lösen (Ausschnitt aus unserem WebAuthn-Paket für 5.5):

{
    "config": {
        "prepend-autoloader": false,
        "optimize-autoloader": true,
        "platform": {
            "php": "7.2.24"
        }
    },
    "require": {
        *snip*
    },
    "replace": {
        "chrisjean/php-ico": "1.0.4",
        "erusev/parsedown": "1.7.4",
        "ezyang/htmlpurifier": "v4.13.0",
        "guzzlehttp/guzzle": "7.3.0",
        "guzzlehttp/promises": "1.4.1",
        "guzzlehttp/psr7": "2.0.0",
        "laminas/laminas-diactoros": "2.4.1",
        "laminas/laminas-httphandlerrunner": "1.2.0",
        "laminas/laminas-progressbar": "2.7.0",
        "laminas/laminas-stdlib": "3.2.1",
        "laminas/laminas-zendframework-bridge": "1.1.1",
        "paragonie/constant_time_encoding": "v2.4.0",
        "pear/net_idna2": "v0.2.0",
        "pear/pear_exception": "v1.0.2",
        "pelago/emogrifier": "v6.0.0",
        "psr/http-client": "1.0.1",
        "psr/http-factory": "1.0.1",
        "psr/http-message": "1.0.1",
        "psr/http-server-handler": "1.0.1",
        "ralouphie/getallheaders": "3.0.3",
        "sabberworm/php-css-parser": "8.3.1",
        "scssphp/scssphp": "v1.8.1",
        "symfony/css-selector": "v5.3.4",
        "symfony/polyfill-mbstring": "v1.23.1",
        "symfony/polyfill-php73": "v1.23.0",
        "symfony/polyfill-php74": "v1.23.0",
        "symfony/polyfill-php80": "v1.23.1",
        "true/punycode": "v2.1.1"
    }
}

Die "replace":-Sektion sorgt dafür, dass diese Pakete nicht mit installiert werden. Generiert ist das mit jq '.packages | map({ (.name) : (.version) }) |add' < composer.lock.

Quote from MysteryCode

Als Knackpunkt sehe ich hier das Versionsmanagement, wenn Paket A Guzzle 5.0 will, Paket B aber 5.1.

Zum Einen das, wobei das zumindest bei den Minor-Versionen noch nicht so schlimm ist. Es ist aber vor allem undefiniert, welche Version installiert wird, da die Entscheidung zum Zeitpunkt der Installation passiert und nicht zum Zeitpunkt der Entwicklung. Das ist kaum zu Testen, gerade da die genauen Versionen auch noch von anderen installierten Paketen abhängig und auch von der PHP-Version, die auf dem System läuft. Ich habe in der Vergangenheit schon häufiger Situationen gehabt, bei denen der Abhängigkeitsgraph einfach kaputt war, weil die Anforderungen widersprüchlich waren.

Im WebAuthn-Paket haben wir beispielsweise aktuell die Situation, dass:

• Paket A in der mit PHP 7.2 kompatiblen Version benötigt offiziell Paket B in Version 0.8.x
• Paket B ist erst ab Version 0.9.x mit PHP 8.1 kompatibel.
• Die Version von Paket A, die offiziell mit Version 0.9.x von B kompatibel ist, ist nicht mehr mit PHP 7.2 kompatibel.

Technisch ist B in 0.9.x aber API-kompatibel mit 0.8.x, sodass ich composer so konfigurieren konnte, dass der Version 0.9.x installiert, aber für die Auflösung der Abhängigkeiten vorgibt, dass es Version 0.8.x wäre.

Zum anderen stellt Composer natürlich auch Anforderungen an das System, die ein handelsüblicher Webspace nicht wirklich leisten kann. Der SAT-Solver benötigt bei komplexen Abhängigkeiten recht viel Arbeitsspeicher, Pakete können potentiell aus einem git installiert werden, composer dokumentiert (meines Wissens) keine API zur automatischen Verwendung.

Summa summarum können wir den Vorschlag hier vermutlich auf „Nicht geplant“ setzen.

Hallo,

Quote from Syntafin

Darf man kurz fragen, wie genau die "automatische Verwendung" gemeint ist?

gemeint hatte ich damit eine PHP-API abseits des CLI-Interfaces.

Hallo,

wie schon zuvor angedeutet, sehen wir das technisch nicht als praktikabel an. Im Rahmen der Plugin-Store-Prüfung habe ich jetzt auch schon bei mehreren (Entwickler-)Paketen auf die "replace"-Sektion in der composer.json hingewiesen, um Duplikate zu vermeiden und allgemein liefern wir mit WoltLab Suite Core mittlerweile auch eine ganze Reihe an allgemein nützlichen Bibliotheken mit.