Composer - nur Entwicklung oder auch 'live'?

[tomBuilder]

############
MOD: Thema von hier abgetrennt: https://www.php.de/forum/webentwickl...55#post1532755
#############

Ich installiere den Swiftmailer doch über den Composer oder nicht?

Klar aber auf Deinem Entwicklungsrechner. Auf dem Produktivsystem wird niemals nie nicht Composer genutzt. Dort ird einfach nur das fertig installierte vom Entwicklungssystem hinkopiert.

Nein, auch auf Entwicklungsumgebungen werden üblicherweise Installations Werkzeuge benutzt.

[Ulfikado]

Nein, auch auf Entwicklungsumgebungen werden üblicherweise Installations Werkzeuge benutzt.

Was heist Nein? Genau das schrieb ich doch!

[tomBuilder]

Was heist Nein? Genau das schrieb ich doch!

No means no!
Der Composer ist ein Installationswerkzeug für Entwicklung-, Test-; und Produktiv-Umgebungen.

[Ulfikado]

No means no!
Der Composer ist ein Installationswerkzeug für Entwicklung-, Test-; und Produktiv-Umgebungen.

Alter Schwede… das ist doch Quatsch was Du da schreibst! Composer ist ein Entwicklerwerkzeug. Wenn Du den in Produktivsystemen nutzt hast Du gerade Deinen Fehler entdeckt!

Ferner würde das u.U. bedeuten das alle die keinen eigenen Server btreiben keine Composer-Packete benutzen könnten wenn sie keinen Composer installiert bekommen.

Ich erklär es mal:

Du als Entwickler baust Deine Anwendung auf dem Entwicklungssystem in dem Du u.U. mit Composer Deine Packete und deren Abhängigkeiten installierst & auflöst.

Auf Test- und Produktivsystemen darf sich an diesen Packeten und Abhängigkeiten im Bezug aus DEV natürlich nichts mehr ändern, sonst würde das den Sinn dieser Systeme ja ad absurdum führen.
Somit ist der Einsatz von Composer für diese Systeme in keiner Weise mehr nötig! Genau für dieses Szenario wurde composer entwickelt. Es ist unnötig und falsch composer ausserhalb eines DEV systems nutzen zu wollen!

[tomBuilder]

Alter Schwede… das ist doch Quatsch was Du da schreibst!

Dito, ich kenne Deine Meinung, halte diese nach wie vor für falsch.

Wie ich ja schon erwähnte sehen das auch andere anders.
So gibt es Optimierungen für den Composer, welche man nur in productiven Umgebungen nutzen sollte.
schon allein das kann zum nachdenken anregen.
wozu require-dev wochl gedacht ist, verstehe ich innerhalb Deiner Argumentation auch nicht.


Ihr deployed - meintest Du mal - mit vendor im git, was auch nicht nur ich für einen gravierenden Fehler halte.
Du darfst gerne machen was Du willst, auch at work, aber es ist eben nicht so gedacht und untypisch.

Deine Erkärung lässt mich an Deinem Verständniss vom Composer sehr zweifeln, macht nüscht.

Es ist richtig, dass man unter Umständen gezwungen ist ein koplettes Verzeichniss hochzuladen, schlechte Webspace Angebote sind einfach ärgerlich.

[Ulfikado]

Dito, ich kenne Deine Meinung, halte diese nach wie vor für falsch.

Code auf Test und Produktivsystemen hat sich nicht zu ändern! Punkt

Wie ich ja schon erwähnte sehen das auch andere anders.

Bitte sprich nur für Dich! Andere können selbst ihre Meinung schreiben.

Wer ist "andere" denn? Ich habe da von der letzten Diskusion zu dem Thama ganz andere Meinungen in erinnerung.

So gibt es Optimierungen für den Composer, welche man nur in productiven Umgebungen nutzen sollte.

welche wären das denn z.B?

Nachtrag: möglicher Weise meinst Du die autoloeder optimierungen? https://getcomposer.org/doc/articles...ptimization.md
Aber da ist nur das Caching ein Problem. Aber mal ehrlich dann nutze halt 2 unterschiedliche build-Prozesse für DEV und PROD

wozu require-dev wochl gedacht ist, verstehe ich innerhalb Deiner Argumentation auch nicht.

Doku lesen könnte helfen!

https://getcomposer.org/doc/04-schema.md#require-dev :
Lists packages required for developing this package, or running tests, etc

Oder auf Deutsch, dort werden die Packete definiert die nur für die Entwicklung benötigt werden. Das steht in keinerlei Widerspruch zu meiner Argumentation.

Ihr deployed - meintest Du mal - mit vendor im git,

Das hab ich so nie gesagt oder geschrieben! Was ich schrieb war das es u.U. mal die Notwendigkeit geben könnte das zu machen. Nähmlich dann wenn Du eine fertige Anwendung zum Kunden bringen willst. Der Kunde hat nix mit Composer zu tun hat und wie bereits mehrfach erwähnt Composer ein Entwicklertool ist.

Es wär nett wenn Du Deine Diskusion nen bischen mehr auf Fakten aufbauen würdest.

I was auch nicht nur ich für einen gravierenden Fehler halte.

Bitte sprich nur für Dich! Andere können selbst ihre Meinung kund tun.

[tomBuilder]

wenn Dir schon in Deiner Argumentation kein Wiederspruch aufällt.
Naja immerhin hast Du diesen a posteriori verneint - auch ne Art sich die Meinung schönzureden.

Bitte sprich nur für Dich! Andere können selbst ihre Meinung kund tun.

Tuen Sie auch, bei Issues auf Guthub, bei FAQ's und nicht zulezt hier im Forum.

Lese doch die Threads hier im Forum oder die FAQ*'s der genutzen Produkte.

[Zeichen32]

Composer hat mit Absicht eine composer.lock wo die genauen Abhängigkeiten mit Ihren Versionen hinterlegt werden. So das man seine Software auf jedem System mit den selben Abhängigkeiten wie in der Entwicklung deployen kann. Auch ist die Composer Datei sehr wichtig für die Tests. Als Beispiel ein Symfony Bundle welches für die Version 3 und 4 entwickelt wurde. Im automatischen Build System kann ich dann über eine Versionsmatrix mit Hilfe von Composer jede Abhängigkeitenversion durchtesten. Nach deinem Beispiel müsste ich ja dann verschiedene Branches mit den einzelnen Vendor Versionen haben?

[lottikarotti]

Wir nutzen einen Build-Server der alle Abhängigkeiten bei jedem Deployment-Vorgang neu installiert (das Cachen wir über einen internen Proxy), die Tests ausführt und bei Erfolg den Build live schaltet (grob beschrieben). Die Vendor-Verzeichnisse werden dabei vom Git-Repository *ignoriert*. Meine Meinung liegt da irgendwo zwischen den beiden Streithähnen, aber näher beim tom

[jspit]

Ich nutze selber ja Composer nicht bzw. selten, hab aus Interesse eine Frage die hier m.E. reinpasst.

Composer löst ja automatisch Abhängigkeiten auf. Wenn ich z.B. ein bekanntes Paket X per Composer installiere und dort wird in der akt.Version jetzt neu ein Paket Y benutzt, dann wird Y ja für mich fast unbemerkt mit installiert.
Die Kette kann noch weiter gehen, wenn Y noch A, B und C braucht. Wir wird immer unwohl im Magen, wenn "automatisiert" und unbemerkt Skripte auf Rechnern installiert werden. Heist es nicht immer traue nie dem was von draußen rein kommt?
Nun gibt es Kommandos/Skripte welche solche Abhängigkeiten zeigen. Auf meinem Entwicklungssystem habe ich da noch die Kontrolle, wenn ich mich mit Composer & Co gut auskenne.
Wie ist es bei Einsteigern? Kann Anfängern immer bedenkenlos Composer empfohlen werden oder ist es letztlich nicht wie bei anderen Werkzeugen, das für die Benutzung ein bestimmtes Maß an Kenntnissen erforderlich ist?
Und nun wird per Composer auf Produktivsystemen installiert? Wie wird da die Sicherheit gewährleistet?

[Zeichen32]

Man sollte natürlich vorher schauen, welche Abhängigkeiten ein Paket hat. Desweiteren gibt es ua. noch den SecurityChecker (https://github.com/sensiolabs/security-checker) welcher Beispielsweise bei Symfony auch direkt dabei ist. Hat ein Paket Version eine bekannte Sicherheitslücke, wird man beim installieren direkt gewarnt.

Am Ende ist es aber wie bei jedem PaketManager, egal ob NPM, Composer, Marven, usw. oder ob man es per Hand installiert:
Erst schauen, dann verwenden.

Über "composer show --tree / -t package/name" kann man sich den Abhängigkeitsbaum übrigens anzeigen lassen.