Ich habe composer installiert und einige Pakete über 'composer install' hinzugefügt. Sie hat sie unter dem Pfad "my_project \ vendor" installiert, aber einige der Pakete wurden mit git geklont. Als ich "mein_projekt" festlegte, wurden diese geklonten Pakete ignoriert.
Das Problem ist, dass wenn andere Entwickler "my_project" klonen, ihnen die Pakete fehlen, die ignoriert wurden. Gibt es eine Möglichkeit, die Pakete automatisch zu "my_project" hinzuzufügen, damit andere Entwickler sie von mir holen?
Ich denke, das sollte mit Submodulen gemacht werden, aber ich weiß nicht, wie ich automatisch jedes neue Paket von Composer als Submodul zu meinem Projekt hinzufügen kann.
Vorwort: Jordi - Ich liebe Komponisten, mach weiter so, und wenn ich mich irre, lass es mich wissen und ich werde meinen Workflow aktualisieren und den Beitrag bearbeiten: D
Leider ist das nicht die "allgemeine Empfehlung", je nachdem, wen Sie fragen, es ist bei Weitem eine reine Entwickler-Perspektive. Und die Vorbehalte, die in den Komponisten-FAQs vorgeschriebene Praxis anzuwenden, haben viel mehr Überlegungen, als ich hier behandeln kann. Also überlasse ich ein paar wichtige Punkte für die Berücksichtigung anderer.
By @ Seldaek eigene Aufnahme Komponist ist nicht wirklich 100% stabil, weit besser als vor einem Jahr, aber trotzdem ein sehr aktives Projekt . Sich auf Composer zu verlassen, um eine identische Umgebung auf einem Dev-Server gegenüber einem Staging-Server gegenüber einem Produktionsserver zu implementieren, wäre keine allgemeine Empfehlung von irgendeiner QA / Bereitstellungsgruppe. Dies ist für Jordi kein leichtes Unterfangen, sondern eher ein Ausdruck der matikulösen Natur der QA-Völker.
In den FAQ wird angegeben, dass beim Zusammenführen von Hersteller-Bibliotheken in Ihr eigenes Repository Folgendes zu beachten ist:
Beschränken Sie sich auf die Installation markierter Releases (keine dev-Versionen)
Wenn Sie jedoch composer verwenden, um Ihre CI- oder automatisierten Bereitstellungen zu verwalten, würde die gleiche Einschränkung gelten - nur more - da die Bereitstellung eines Master- oder Entwickler-Tags in Ihrer Produktionsumgebung ein sein kann sehr anderes Paket als das, was Sie beim Staging vor nur einem Tag oder sogar einer Stunde getestet haben.
Auch außerhalb von Änderungen in Third-Party-Bibliotheken (die nur durch getaggte Versionen unabhängig von Entwickler- oder Produktionsbereitstellungen gelöst werden) können Sie sich darauf verlassen, dass der Compiler jedes Mal das gleiche tut Produktion. Dies ist nicht wirklich ein Risikofall, mit dem ich mich beschäftigen würde, aber andererseits bin ich auch ein Entwickler;) Aber Probleme können sich ergeben aus einfache Änderungen wie diese . Wenn Sie nicht genau die gleiche Version von composer.phar in allen Umgebungen verwenden, könnten Sie einen Staging- oder Produktionsserver wirklich vermasseln.
Das andere wichtige Thema, das ich habe, bezieht sich wirklich auf alle Punkte, die unter dieser Überschrift aufgeführt sind:
Während es in einer Umgebung verlockend sein kann, es zu begehen, führt es zu einigen Problemen:
Ich sehe die Folgen nicht als Probleme, sondern als Vorteile! Ein großes VCS-Repository ist in modernen Umgebungen mit hoher Bandbreite nicht gerade eine große Sache. Und wenn Sie nicht eine sehr aktive Vendor-Bibliothek verwenden, werden Ihre Diffs auch nicht so groß sein. Selbst wenn sie groß waren, sind git / hg / dvcs-Systeme alle in der Lage, Chunks wiederzuverwenden, Chunks zu komprimieren und all Ihre Enten in einer Reihe zu halten. Mehr noch, sie sind eine Warnung für den Entwickler, wenn Änderungen an diesen Paketen vorgenommen werden, und diff -w ist eine großartige Zusammenfassung der gesamten Änderungsmengen, besonders , wenn Sie sich auf Dev / Master-Tags befinden.
Duplizierung des Verlaufs aller Ihrer Abhängigkeiten in Ihrem eigenen VCS.
Dies ist ein wenig falsch formuliert, es wird nicht den gesamten Commit-Verlauf der Vendor-Bibliothek duplizieren, sondern nur einen einzigen Commit (Ihr Commit), der das gesamte Delta zwischen jetzt und dem letzten Mal enthält, an dem Sie ein Composer-Update durchgeführt haben . Wahrscheinlich aktualisieren Sie nicht alle Ihre Bibliotheken bei jedem Update, auch wenn Sie keine einzelnen Pakete angeben. Und wenn Sie versehentlich eine Vendor-Lib aktualisiert haben, können Sie sie leicht zurücksetzen, während Sie, wenn Sie dies auf einem Dev / Master-Tag getan haben und Ihre Umgebung zerstört haben, herausfinden müssen, welche Version Sie zuvor verwendet haben und das Tag angeben composer.json und aktualisieren Sie sie erneut, um sie wiederherzustellen. git checkout /vendor/3rdpartylib --force scheint mir einfach einfacher.
Das Hinzufügen von Abhängigkeiten, die über git zu einem git-Repo installiert werden, zeigt sie als Submodule an. Dies ist problematisch, da es sich nicht um echte Submodule handelt und Sie auf Probleme stoßen werden.
Im Idealfall würde Composer Ihnen eine Konfigurationsoption geben. Es könnte automatisch das .git-Verzeichnis von git pulls löschen und automatisch das Verzeichnis (oder temporär mv it) vor dem Aktualisieren einer lib rm, wenn und nur wenn eine aktualisierte Version existiert. Und das wäre viel zuverlässiger, als diesen manuellen Prozess einzelnen Entwicklern zu überlassen. Es gibt eine ebenso große Anzahl von Gründen, warum Hersteller-Bibliotheken in Ihr Versionskontroll-Repository integriert werden müssen, damit die Auswahl wirklich von den Details Ihrer Situation abhängt.
Der Hauptgrund für die Versionierung aller Ihrer Dateien ist die zuverlässige Bereitstellung des genauen Pakets, das Sie in der Entwicklung getestet haben, für die Bereitstellung in der Produktion. Dies ist ein wichtiger Grund für vcs und automatisierte Bereitstellungen. Es sei denn, Sie konfigurieren Ihre Entwicklungsumgebung so, dass für jedes Paket bestimmte Tags verwendet werden und Ihre Version den Composer steuert.phar sollten Sie sich nicht auf Composer verlassen, um Ihre Software zu implementieren.
Tags und Links php git-submodules composer-php