2012-06-21 9 views
10

Seit der zweiten Ausführung von bundle install werden Abhängigkeiten von Gemfile.lock geladen, solange Gemfile nicht geändert wird.Was passiert beim direkten Ändern von Gemfile.lock?

Aber ich frage mich, wie Erkennung von Änderungen zwischen diesen beiden Dateien vorgenommen wird.

Zum Beispiel, wenn ich eine neue Abhängigkeit direkt in Gemfile.lock hinzufügen, ohne es in Gemfile hinzuzufügen (im Gegensatz zu der bewährten Methode, da Gemfile.lock automatisch aus Gemfile generiert wird), würde ein bundle install Gemfile als betrachten geändert ?

In der Tat vergleicht bundle install Prozess die gesamten Gemfile und Gemfile.lock Bäume, um Änderungen zu erkennen?

Wenn es ist, selbst wenn ich eine Abhängigkeit direkt zu Gemfile.lock hinzufügen würde, würde Gemfile als geändert erkannt werden (da anders) und würde Gemfile.lock wieder löschen (so die addierte Abhängigkeit verlieren ...)

Was ist der Prozess von bundle install seit dem Start zum zweiten Mal?

mehr klar zu sein, meine Frage ist:

werden nur von Gemfile Änderungen basieren? Das heißt, Bundler würde einen Gemfile-Snapshot von jeder bundle install Ausführungsnummer N behalten und vergleicht ihn lediglich mit der bundle install Ausführung N + 1?

Oder keine Snapshots werden im Bundler-Speicher erstellt und Bundler führt jedes Mal einen Vergleich mit Gemfile.lock durch, um festzustellen, ob Gemfile als geändert betrachtet werden muss.

+0

Löschen Sie einfach Gemlock-Datei, legen Sie Ihre erforderlichen Edelsteine ​​in Gem-Datei und führen Sie "Bundle installieren". Das ist es. Ich denke nicht, dass es eine gute Idee ist, viel über die Gemlock-Datei nachzudenken. ;) – uday

+0

@uDaY Ich stimme dir zu, aber ich bin neugierig auf den Prozess unter der Haube von Bundle installieren :) – Mik378

+3

Haben Sie gelesen [diese] (http://gembundler.com/rational.html) und [diese] (http://gembundler.com/man/bundle-install.1.html)? –

Antwort

15

Wenn Sie Ihre Gemfile.lock bearbeiten, würde die Rails-App von einer anderen Version von Gems abhängen ... Die Integrität Ihres Gem-Versionsverwaltungssystems wäre in diesem Fall gebrochen. Es ist eine sehr, sehr schlechte Idee, Gemfile.lock Datei direkt zu bearbeiten.

Bitte, ein guter Kerl und Geschäfte machen mit Gemfile nur

1

Ich weiß, diese Frage ist sehr alt, aber ich hatte vor kurzem ich meine eigene Antwort befassen sich mit diesem so gebe. Omniauth wurde kürzlich auf Version 1.3.2 aktualisiert, um ein Sicherheitsproblem zu beheben. Ich wurde damit beauftragt, Omniahuth auf diese neue gepatchte Version zu aktualisieren, aber nachdem wir unsere Gemfile überprüft hatten, wurde mir klar, dass wir diesen Edelstein nicht dort hatten. Also habe ich gesagt, vielleicht kann ich einfach die Version von Gemfile.lock von 1.3.1 auf 1.3.2 umstellen. Lange Rede, kurzer Sinn, das hätte funktioniert, aber es stellte sich heraus, dass ich es nicht so machen musste. Was ich am Ende tun wurde mit dem folgenden Befehl

bundle update omniauth --patch

die in der gleichen Veränderung resultiert ich manuell tun würde:

- omniauth (1.3.1) 
+ omniauth (1.3.2) 

Das heißt, wenn Sie denken, Sie Änderungen vornehmen müssen Zu Gemfile.lock gibt es wahrscheinlich eine Möglichkeit, diese Änderung vorzunehmen, ohne den Gemfile.lock selbst zu berühren. Tun Sie einfach bundle --help und Sie werden wahrscheinlich finden und die Option zu tun, was Sie erreichen möchten.

Verwandte Themen