it-swarm.com.de

Sollte composer.lock zur Versionskontrolle verpflichtet sein?

Ich bin etwas verwirrt mit composer.lock, der in einer Anwendung mit einem Repository verwendet wird.

Ich habe viele Leute gesehen, die sagten, wir sollten nicht aus dem Repository .gitignorecomposer.lock.

Wenn ich meine Bibliotheken in meiner Entwicklungsumgebung aktualisiere, habe ich einen neuen composer.lock, aber ich kann sie nicht in der Produktion aktualisieren.

Erzeugt es keine Konflikte in dieser Datei?

456

Wenn Sie Ihre Bibliotheken aktualisieren, möchten Sie auch die Sperrdatei festschreiben. Es gibt im Wesentlichen an, dass Ihr Projekt an die spezifischen Versionen der von Ihnen verwendeten Bibliotheken gebunden ist.

Wenn Sie Ihre Änderungen festschreiben und jemand Ihren Code abruft und die Abhängigkeiten aktualisiert, sollte die Sperrdatei unverändert bleiben. Wenn es geändert wird, bedeutet dies, dass Sie eine neue Version von etwas haben.

Wenn Sie sich im Repository befinden, können Sie sicherstellen, dass jeder Entwickler dieselbe Version verwendet.

596
meza

Für Anwendungen/Projekte: Definitiv ja.

Die Composer-Dokumentation stellt dazu (mit Schwerpunkt) fest:

Übertragen Sie die Anwendung composer.lock Ihrer Anwendung (zusammen mit composer.json) in die Versionskontrolle.

Wie @meza sagte: Sie sollten die Sperrdatei festlegen, damit Sie und Ihre Mitarbeiter an denselben Versionen von Versionen arbeiten und verhindern, dass Sie Aussprüche wie "Aber es hat auf meinem Computer funktioniert" finden. ;-)

Für Bibliotheken: Wahrscheinlich nicht.

Die Dokumentation des Komponisten enthält folgende Hinweise:

Hinweis: Für Bibliotheken wird nicht unbedingt empfohlen, die Sperrdatei zu übergeben (...)

Und sagt hier :

Wenn Sie möchten, können Sie für Ihre Bibliothek die Datei composer.lock festlegen. Dies kann Ihrem Team dabei helfen, immer mit denselben Abhängigkeitsversionen zu testen. Diese Sperrdatei hat jedoch keine Auswirkungen auf andere Projekte, die davon abhängig sind. Es hat nur Auswirkungen auf das Hauptprojekt.

Für Bibliotheken stimme ich der Antwort von @Josh Johnson zu.

162
Jeroen Fiege

Nachdem ich für ein paar Projekte beide Wege unternommen habe, gehe ich davon aus, dass composer.lock nicht als Teil des Projekts festgeschrieben werden sollte. Ich weiß, dass es einfacher ist, dies zu tun, aber bitte halten Sie sich bei mir, wenn ich dafür einen Fall mache.

composer.lock ist Build-Metadaten, die nicht Teil des Projekts sind. Der Zustand der Abhängigkeiten sollte durch die Art der Versionsverwaltung (entweder manuell oder als Teil des automatisierten Buildprozesses) und nicht willkürlich vom letzten Entwickler festgelegt werden, um sie zu aktualisieren und die Sperrdatei zu übergeben.

Wenn Sie sich Sorgen machen, ob sich Ihre Abhängigkeiten zwischen Composer-Aktualisierungen ändern, haben Sie kein Vertrauen in Ihr Versionsschema. Versionen (1.0, 1.1, 1.2 usw.) sollten unveränderlich sein und Sie sollten "dev-" und "X. *" - Platzhalter außerhalb der anfänglichen Feature-Entwicklung vermeiden.

Das Festschreiben der Sperrdatei ist eine Regression für Ihr Abhängigkeitsverwaltungssystem, da die Abhängigkeitsversion jetzt wieder implizit definiert ist.

Außerdem sollte Ihr Projekt niemals neu erstellt werden müssen, oder seine Abhängigkeiten müssen in jeder Umgebung neu festgelegt werden. Ihr Lieferumfang (tar, zip, phar, ein Verzeichnis usw.) sollte unveränderlich sein und durch Umgebungen beworben werden, ohne den Status zu ändern.

Edit: Ich wusste, dass dies keine beliebte Antwort wäre, aber wenn Sie die Abstimmung ablehnen, wären Sie so freundlich, in den Kommentaren einen Grund anzugeben, der auf den Fehler in der Antwort hinweist. Vielen Dank!

65
Josh Johnson
  1. Sie sollten Ihre Abhängigkeiten nicht direkt in der Produktion aktualisieren. 
  2. Sie sollten Ihre composer.lock -Datei versionieren.
  3. Sie sollten Ihre tatsächlichen Abhängigkeiten nicht versionieren.

1. Sie sollten Ihre Abhängigkeiten nicht direkt in Production aktualisieren , weil Sie nicht wissen, wie sich dies auf die Stabilität Ihres Codes auswirkt. Es könnten Fehler bei den neuen Abhängigkeiten auftreten, es kann sich das Verhalten des Codes ändern, der sich auf Ihr eigenes Verhalten auswirkt, er kann mit anderen Abhängigkeiten nicht kompatibel sein usw. Sie sollten dies in einer Entwicklungsumgebung tun, gefolgt von ordnungsgemäßer QS und Regressionstests usw. .

2. Sie sollten Ihre composer.lock -Datei versionieren, da dies Informationen über Ihre Abhängigkeiten und über die Abhängigkeiten Ihrer Abhängigkeiten speichert, mit denen Sie den aktuellen Status des Codes replizieren können. Dies ist wichtig, da alle Tests und Entwicklungen mit spezifischem Code durchgeführt wurden. Wenn Sie sich nicht um die tatsächliche Version des Codes kümmern, die Sie haben, ähnelt das Hochladen von Codeänderungen in Ihre Anwendung und nicht das Testen. Wenn Sie Ihre Abhängigkeitsversionen aktualisieren, sollte dies eine freiwillige Handlung sein, und Sie sollten die nötige Sorgfalt walten lassen, um sicherzustellen, dass alles noch funktioniert. Wenn Sie eine oder zwei Stunden Betriebszeit verlieren und eine frühere Release-Version wiederherstellen, kann dies eine Menge Geld kosten.

Eines der Argumente, die Sie sehen werden, wenn Sie composer.lock nicht benötigen, ist, dass Sie die genaue Version, die Sie benötigen, in Ihrer composer.json -Datei festlegen können, und zwar auf diese Weise jedes Mal, wenn Sie jemand sind Wenn composer install ausgeführt wird, wird derselbe Code installiert. Dies ist nicht zutreffend, da Ihre Abhängigkeiten ihre eigenen Abhängigkeiten haben und ihre Konfiguration möglicherweise in einem Format angegeben wird, in dem Aktualisierungen von Unterversionen oder sogar ganze Versionen möglich sind. 

Dies bedeutet, dass Laravel in der Datei composer.json möglicherweise auch eigene Abhängigkeiten hat, wenn Sie angeben, dass Laravel 4.1.31 in Ihrer composer.json enthalten sein soll. 2. * . Mit dieser Art von Konfiguration könnten Sie Laravel 4.1.31 mit Symfony Event-Dispatcher 2.4.1 beenden, und jemand anderes in Ihrem Team könnte Laravel 4.1.31 mit Event-Dispatcher 2.6.5 haben, das wäre alles hängen Sie davon ab, wann Sie die Composer-Installation zuletzt ausgeführt haben.

Wenn Sie Ihre composer.lock -Datei im Versionssystem haben, wird die genaue Version dieser untergeordneten Abhängigkeiten gespeichert. Wenn Sie und Ihr Teamkollege einen Composer installieren, installieren Sie die Abhängigkeiten auf dieser Grundlage Bei einem composer.lock) erhalten Sie beide die gleiche Version.

Was ist, wenn Sie ein Update durchführen möchten? Führen Sie dann in Ihrer Dev-Umgebung Folgendes aus: composer update, dies generiert eine neue composer.lock -Datei (falls etwas neues vorhanden ist) und nachdem Sie es getestet haben, und QA-Test und Regressionstest es und so weiter. Sie können es für alle anderen vorschieben, die neue composer.lock herunterzuladen, da sie sicher aktualisiert werden kann.

3. Sie sollten Ihre tatsächlichen Abhängigkeiten nicht versionieren , weil dies keinen Sinn macht. Mit dem composer.lock können Sie die genaue Version der Abhängigkeiten installieren und müssen sie nicht festschreiben. Warum sollten Sie zu Ihrem Repo 10000 Dateien mit Abhängigkeiten hinzufügen, wenn Sie sie nicht aktualisieren möchten. Wenn Sie eines davon ändern müssen, sollten Sie es zusammenfassen und dort Ihre Änderungen vornehmen. Und wenn Sie sich Sorgen machen, dass Sie die tatsächlichen Abhängigkeiten jedes Mal eines Builds oder Releases abrufen müssen, hat Composer verschiedene Möglichkeiten, um dieses Problem zu beheben, Cache-Speicher, ZIP-Dateien usw.

26
lebobbi

Sie geben dann den composer.json für Ihr Projekt ein und alle anderen Mitglieder Ihres Teams können Composer-Installation ausführen, um Ihre Projektabhängigkeiten zu installieren.

Die Sperrdatei soll die genauen installierten Versionen aufzeichnen, damit sie erneut installiert werden können. Das bedeutet, wenn Sie eine Versionsspezifikation von 1. * haben und Ihr Mitarbeiter ein Composer-Update ausführt, das 1.2.4 installiert und dann die composer.lock-Datei festschreibt, werden Sie bei der Composer-Installation auch 1.2.4 erhalten wenn 1.3.0 veröffentlicht wurde. Dadurch wird sichergestellt, dass alle Projektmitarbeiter dieselbe Version haben.

Wenn also seit der letzten Composer-Installation etwas zugesagt wurde, erhalten Sie ohne Sperrdatei neuen Code von Drittanbietern, der heruntergezogen wird.

Auch dies ist ein Problem, wenn Sie besorgt sind, dass Ihr Code fehlerhaft ist. Dies ist einer der Gründe, warum es wichtig ist, an Composer zu denken, der sich auf die composer.lock-Datei konzentriert.

Quelle: Komponist: Es geht um die Sperrdatei .


Übertragen Sie die Anwendung composer.lock Ihrer Anwendung (zusammen mit composer.json) in die Versionskontrolle. Dies ist wichtig, da der Installationsbefehl prüft, ob eine Sperrdatei vorhanden ist. Wenn dies der Fall ist, werden die dort angegebenen Versionen heruntergeladen (unabhängig davon, was composer.json sagt). Dies bedeutet, dass jeder, der das Projekt eingerichtet hat, dieselbe Version der Abhängigkeiten herunterladen wird. Ihr CI-Server, Ihre Produktionsmaschinen, andere Entwickler in Ihrem Team, alles und alle arbeiten mit den gleichen Abhängigkeiten, wodurch die Möglichkeit von Fehlern verringert wird, die nur einen Teil der Bereitstellungen betreffen. Selbst wenn Sie alleine entwickeln, können Sie sich bei der Neuinstallation des Projekts innerhalb von sechs Monaten darauf verlassen, dass die installierten Abhängigkeiten weiterhin funktionieren, auch wenn Ihre Abhängigkeiten seitdem viele neue Versionen freigeben.

Quelle: Composer - Grundlegende Verwendung .

6
waanders

Es gibt keine genaue Antwort darauf.

Im Allgemeinen sollte Composer nicht das tun, was das Build-System tun soll, und Sie sollten composer.lock nicht in VCS einfügen. Der Komponist könnte es seltsamerweise verkehrt herum haben. Endbenutzer sollten keine Sperrdateien verwenden, anstatt zu produzieren. Normalerweise speichert Ihr Build-System Snapshots, wiederverwendbare Verzeichnisse usw. und nicht jedes Mal ein leeres Verzeichnis. Leute, die eine Bibliothek vom Komponisten auschecken, möchten möglicherweise, dass diese Bibliothek eine Sperre verwendet, damit die Abhängigkeiten, mit denen die Bibliothek geladen wird, getestet werden.

Auf der anderen Seite erhöht dies die Belastung der Versionsverwaltung erheblich, da mit ziemlicher Sicherheit mehrere Versionen jeder Bibliothek benötigt werden, da Abhängigkeiten streng gesperrt werden. Wenn es wahrscheinlich ist, dass jede Bibliothek eine etwas andere Version hat, benötigen Sie Unterstützung für mehrere Bibliotheksversionen, und Sie können auch schnell feststellen, wie groß die benötigten Abhängigkeiten sein müssen. Daher empfiehlt es sich, diese auf dem Blatt zu lassen.

Unter Berücksichtigung dessen finde ich Sperrdateien weder für Bibliotheken noch für Ihre eigenen Arbeitsverzeichnisse nützlich. Es wird nur von mir in meiner Build/Testing-Plattform verwendet, die alle extern erworbenen Assets beibehält und nur dann aktualisiert, wenn dies angefordert wird. Dies ermöglicht wiederholbare Builds zum Testen, Erstellen und Bereitstellen. Während dies in VCS beibehalten werden kann, wird es nicht immer in der Quellstruktur beibehalten, sondern die Build-Bäume befinden sich entweder an einer anderen Stelle in der VCS-Struktur oder werden von einem anderen System an einer anderen Stelle verwaltet. Wenn es in einem VCS gespeichert ist, ist es fraglich, ob es im selben Repo wie die Quellbäume bleiben soll oder nicht, da ansonsten jeder Pull eine Menge Build-Assets einbringen kann. Ich mag es sehr, alles in einem übersichtlichen Repo zu haben, mit Ausnahme von Produktion/sensiblen Referenzen und Aufblähen.

SVN kann es besser als Git, da es Sie nicht zwingt, das gesamte Repo zu erwerben (obwohl ich vermute, dass dies auch nicht unbedingt für Git erforderlich ist, aber die Unterstützung dafür ist begrenzt und es wird nicht häufig verwendet). Einfache Build-Repos sind normalerweise nur ein Überlagerungszweig, in den Sie den Build-Baum zusammenführen/exportieren. Einige Leute kombinieren externe Ressourcen in ihrem Quellbaum oder trennen weitere, externe, Build- und Quellbäume. In der Regel dient es zwei Zwecken: Build-Caching und wiederholbare Builds. Manchmal ermöglicht es jedoch auch, die einzelnen Builds auf einer bestimmten Ebene voneinander zu trennen, und mehrere Builds können problemlos erstellt werden.

Hierfür gibt es eine Reihe von Strategien, und keine eignet sich besonders gut zum Beibehalten der Quellenliste, es sei denn, Sie behalten externe Quellen in Ihrem Quellenbaum.

Sie haben auch Dinge wie Hashes in der Datei. Wie verschmilzt das, wenn zwei Leute Pakete aktualisieren? Das allein sollte Sie denken lassen, dass dies falsch ausgelegt ist.

Die Argumente, die die Leute für Sperrdateien vorbringen, sind Fälle, in denen sie das Problem sehr spezifisch und restriktiv beurteilt haben. Möchten Sie wiederholbare und konsistente Builds? Schließen Sie den Herstellerordner in VCS ein. Dann beschleunigen Sie auch das Abrufen von Assets und müssen während des Builds nicht auf potenziell beschädigte externe Ressourcen angewiesen sein. Keine der von mir erstellten Build- und Deployment-Pipelines erfordert externen Zugriff, sofern dies nicht unbedingt erforderlich ist. Wenn Sie eine externe Ressource aktualisieren müssen, ist dies einmalig. Was der Komponist erreichen möchte, ist für ein verteiltes System sinnvoll, es sei denn, es macht keinen Sinn, wie bereits erwähnt, da die Bibliotheksabhängigkeit für Bibliotheksaktualisierungen mit häufigen Konflikten und Aktualisierungen so langsam ist wie das am langsamsten zu aktualisierende Paket.

Zusätzlich aktualisiere ich wild. Jedes Mal, wenn ich mich entwickle, aktualisiere und teste ich alles. Es gibt ein sehr sehr kleines Fenster, in das sich eine signifikante Versionsverschiebung einschleichen kann. Auch realistisch gesehen ist es nicht anzunehmen, dass bei Beibehaltung der semantischen Versionierung, die in der Regel für Komponisten gilt, so viele Kompatibilitätsprobleme oder -brüche auftreten.

In composer.json legen Sie die benötigten Pakete und deren Versionen ab. Dort können Sie die Versionen sperren. Diese Pakete weisen jedoch auch Abhängigkeiten mit dynamischen Versionen auf, die von composer.json nicht gesperrt werden (obwohl ich nicht verstehe, warum Sie sie nicht auch selbst dort ablegen konnten, wenn Sie möchten, dass sie versionsgesperrt sind), sodass ein anderer Composer installiert bekommt etwas anderes ohne das schloss. Das interessiert Sie vielleicht nicht sonderlich, oder es hängt davon ab, ob es Ihnen wichtig ist. Sollte es dich interessieren? Wahrscheinlich zumindest ein wenig, um sicherzustellen, dass Sie sich in jeder Situation und bei möglichen Auswirkungen darüber im Klaren sind, aber es kann auch kein Problem sein, wenn Sie immer die Zeit haben, nur DRY auszuführen und irgendetwas zu beheben das wurde aktualisiert.

Der problematische Komponist versucht zu vermeiden, dass es manchmal einfach nicht gibt, und der Ärger, den Komponistensperrdateien verursachen können, ist erheblich. Sie haben absolut kein Recht, den Benutzern mitzuteilen, was sie in Bezug auf Build- oder Quell-Assets tun sollen oder nicht (ob sie an einem separaten VCS teilnehmen sollen), da dies nicht ihre Sache ist. Sie sind nicht der Boss von Ihnen oder mir. "Komponist sagt" ist keine Autorität, sie sind weder Ihr vorgesetzter Offizier noch geben sie jemandem eine Überlegenheit in diesem Bereich. Nur Sie kennen Ihre reale Situation und wissen, was dafür am besten ist. Sie raten Benutzern, die nicht verstehen, wie Dinge funktionieren, möglicherweise zu einer Standardmaßnahme. In diesem Fall möchten Sie dies möglicherweise befolgen, aber ich persönlich bin nicht der Meinung, dass dies ein wirklicher Ersatz dafür ist, zu wissen, wie Dinge funktionieren und in der Lage zu sein, richtig zu arbeiten trainieren Sie Ihre Anforderungen. Letztendlich ist ihre Antwort auf diese Frage eine gute Vermutung. Die Leute, die Komponisten machen, wissen weder, wo Sie Ihren Komponisten aufbewahren sollen, noch sollten sie es tun. Ihre einzige Verantwortung ist es, Ihnen zu sagen, was es ist und was es tut. Darüber hinaus müssen Sie entscheiden, was für Sie am besten ist.

Das Speichern der Sperrdatei ist aus Gründen der Benutzerfreundlichkeit problematisch, da Composer sehr geheim ist, ob Lock oder JSON verwendet, und es nicht immer gut ist, beide zusammen zu verwenden. Wenn Sie install ausführen, wird nur die Sperrdatei verwendet, die angezeigt wird. Wenn Sie also composer.json hinzufügen, wird sie nicht installiert, da sie nicht in Ihrer Sperre enthalten ist. Es ist überhaupt nicht intuitiv, was Operationen wirklich tun und was sie in Bezug auf die json/lock-Datei tun und manchmal scheinen sie nicht einmal sinnvoll zu sein (die Hilfe sagt, dass die Installation einen Paketnamen annimmt, aber wenn sie versucht, ihn zu verwenden, sagt sie nein ).

Um die Sperre zu aktualisieren oder Änderungen von json zu übernehmen, müssen Sie update verwenden und möchten möglicherweise nicht alles aktualisieren. Die Sperre hat Vorrang bei der Auswahl, was installiert werden soll. Wenn es eine Sperrdatei gibt, wird diese verwendet. Sie können das Update etwas einschränken, aber das System ist immer noch ein Chaos.

Das Aktualisieren dauert eine Weile, Gigabyte RAM. Ich vermute auch, wenn Sie ein Projekt aufgreifen, das für eine Weile nicht angerührt wurde, dass es von den Versionen ausgesehen hat, die es hat, was im Laufe der Zeit mehr wird und es wahrscheinlich nicht effizient macht, was es nur erwürgt.

Sie sind sehr, sehr hinterhältig, wenn es darum geht, geheime zusammengesetzte Befehle zu haben, von denen man nicht erwarten kann, dass sie zusammengesetzt sind. Standardmäßig wird der Befehl composer remove angezeigt, um z. B. das Aktualisieren des Composer und das Entfernen des Composer zuzuordnen.

Die Frage, die Sie sich wirklich stellen müssen, ist nicht, ob Sie die Sperre in Ihrem Quellenbaum behalten sollten oder ob Sie sie auf irgendeine Weise beibehalten sollten oder nicht, sondern ob Sie sich fragen sollten, was sie tatsächlich tut, dann können Sie selbst entscheiden wann und wo du es aushalten musst.

Ich werde darauf hinweisen, dass die Möglichkeit, über die Sperre zu verfügen, eine große Bequemlichkeit ist, wenn Sie über eine robuste Strategie für die Persistenz externer Abhängigkeiten verfügen, da diese die Informationen aufzeichnet, die für die Verfolgung (der Ursprünge) und die Aktualisierung hilfreich sind, wenn Sie dies nicht tun dann ist es weder hier noch da. Es ist nicht sinnvoll, wenn Sie dazu gezwungen werden, Ihre Quellbäume zu verschmutzen. In älteren Codebasen kommt es häufig vor, dass die Benutzer viele Änderungen an composer.json vorgenommen haben, die nicht wirklich angewendet wurden und fehlerhaft sind, wenn Benutzer versuchen, composer zu verwenden. Kein composer.lock, kein Desync-Problem.

0
jgmjgm

Wenn Sie besorgt sind, dass der Code beschädigt ist, sollten Sie composer.lock an Ihr Versionskontrollsystem übergeben, um sicherzustellen, dass alle Projektmitarbeiter dieselbe Version des Codes verwenden. Ohne Sperrdatei wird jedes Mal neuer Code von Drittanbietern abgerufen.

Die Ausnahme ist, wenn Sie Meta-Apps verwenden, Bibliotheken, in denen die Abhängigkeiten bei der Installation aktualisiert werden sollten (wie die Zend Framework 2 Skeleton App ). Das Ziel ist also, die neuesten Abhängigkeiten jedes Mal zu erfassen, wenn Sie mit der Entwicklung beginnen möchten.

Quelle: Composer: Es geht um die Sperrdatei

Siehe auch: Was sind die Unterschiede zwischen Composer-Update und Composer-Installation?

0
kenorb