bundle-update - Aktualisieren Sie Ihre Edelsteine auf die neuesten verfügbaren Versionen
bundle update *gems [--all] [--group=NAME] [--source=NAME] [--local] [--ruby] [--bundler[=VERSION]] [--full-index] [--jobs=JOBS] [--quiet] [--patch|--minor|--major] [--redownload] [--strict] [--conservative]
Aktualisieren Sie die angegebenen Gems (alle Gems, wenn das Flag --all verwendet wird) und ignorieren Sie dabei die zuvor installierten Gems, die in Gemfile.lock angegeben sind. Im Allgemeinen sollten Sie bundle install(1) bundle-install.1.html verwenden, um genau dieselben Gems und Versionen auf allen Computern zu installieren.
Sie würden Bundle Update verwenden, um die Version eines Gems explizit zu aktualisieren.
Alle in Gemfile angegebenen Gems aktualisieren.
Aktualisieren Sie nur die Gems in der angegebenen Gruppe. Sie können beispielsweise alle Gems in der Entwicklungsgruppe mit bundle update --group development aktualisieren. Sie können auch bundle updaterails --group test aufrufen, um beispielsweise das Rails-Gem und alle Gems in der Testgruppe zu aktualisieren.
Der Name einer :git- oder :path-Quelle, die in Gemfile(5) verwendet wird. Beispielsweise würden Sie mit einer :git-Quelle von http://github.com/rails/rails.git bundle update --source Rails< aufrufen
Versuchen Sie nicht, Gems aus der Ferne abzurufen und verwenden Sie stattdessen den Gem-Cache.
Aktualisieren Sie die gesperrte Version von Ruby auf die aktuelle Version von Ruby.
Aktualisieren Sie die gesperrte Version des Bundlers auf die aufgerufene Bundler-Version.
Greifen Sie auf die Verwendung des Einzeldateiindex aller Edelsteine zurück.
Geben Sie die Anzahl der Jobs an, die parallel ausgeführt werden sollen. Der Standardwert ist die Anzahl der verfügbaren Prozessoren.
Wiederholen Sie fehlgeschlagene Netzwerk- oder Git-Anfragen so oft Mal.
Es werden nur Warnungen und Fehler ausgegeben.
Erzwinge das Herunterladen jedes Edelsteins.
Aktualisieren Sie lieber nur auf die nächste Patch-Version.
Aktualisieren Sie lieber nur auf die nächste Nebenversion.
Bevorzugen Sie die Aktualisierung auf die nächste Hauptversion (Standard).
Lassen Sie nicht zu, dass Edelsteine nach dem neuesten --patch | aktualisiert werden --moll | --major.
Verwenden Sie bei der Bundle-Installation ein konservatives Aktualisierungsverhalten und lassen Sie keine Aktualisierung indirekter Abhängigkeiten zu.
Wenn Sie bundle update --all ausführen, ignoriert Bundler alle zuvor installierten Gems und löst alle Abhängigkeiten erneut auf, basierend auf den neuesten Versionen aller in den Quellen verfügbaren Gems.
Betrachten Sie die folgende Gemfile(5):
source "https://rubygems.org"
gem "rails", "3.0.0.rc"
gem "nokogiri"Wenn Sie bundle install(1) bundle-install.1.html zum ersten Mal ausführen, löst Bundler alle Abhängigkeiten bis zum Ende auf und installiert, was Sie benötigen:
Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies...
Installing builder 2.1.2
Installing abstract 1.0.0
Installing rack 1.2.8
Using bundler 1.7.6
Installing rake 10.4.0
Installing polyglot 0.3.5
Installing mime-types 1.25.1
Installing i18n 0.4.2
Installing mini_portile 0.6.1
Installing tzinfo 0.3.42
Installing rack-mount 0.6.14
Installing rack-test 0.5.7
Installing treetop 1.4.15
Installing thor 0.14.6
Installing activesupport 3.0.0.rc
Installing erubis 2.6.6
Installing activemodel 3.0.0.rc
Installing arel 0.4.0
Installing mail 2.2.20
Installing activeresource 3.0.0.rc
Installing actionpack 3.0.0.rc
Installing activerecord 3.0.0.rc
Installing actionmailer 3.0.0.rc
Installing railties 3.0.0.rc
Installing rails 3.0.0.rc
Installing nokogiri 1.6.5
Bundle complete! 2 Gemfile dependencies, 26 gems total.
Use `bundle show [gemname]` to see where a bundled gem is installed.Wie Sie sehen, benötigt Ihre Anwendung, obwohl Sie zwei Gems in der Gemfile(5) haben, 26 verschiedene Gems, um ausgeführt zu werden. Bundler merkt sich die genauen Versionen, die es in Gemfile.lock installiert hat. Wenn Sie bundle install(1) bundle-install.1.html das nächste Mal ausführen, überspringt Bundler die Abhängigkeitsauflösung und installiert dieselben Gems wie beim letzten Mal.
Nachdem Sie Gemfile.lock in die Versionskontrolle eingecheckt und auf einen anderen Computer geklont haben, wird die Ausführung von bundle install(1) bundle-install.1.html immer noch ausgeführt Installiere die Gems, die du zuletzt installiert hast. Sie müssen sich keine Sorgen machen, dass eine neue Version von erubis oder mail die von Ihnen verwendeten Gems ändert.
Von Zeit zu Zeit möchten Sie jedoch möglicherweise die von Ihnen verwendeten Gems auf die neuesten Versionen aktualisieren, die immer noch mit den Gems in Ihrer Gemfile(5) übereinstimmen.
Führen Sie dazu bundle update --all aus, das Gemfile.lock ignoriert und alle Abhängigkeiten erneut auflöst. Bedenken Sie, dass dieser Prozess zu einem erheblich anderen Satz der 25 Gems führen kann, basierend auf den Anforderungen neuer Gems, die die Gem-Autoren seit der letzten Ausführung von bundle update --all veröffentlicht haben.
Manchmal möchten Sie ein einzelnes Gem in der Gemfile(5) aktualisieren und die restlichen Gems, die Sie angegeben haben, für die Versionen in der Gemfile.lock gesperrt lassen.
Stellen Sie sich zum Beispiel im obigen Szenario vor, dass nokogiri die Version 1.4.4 veröffentlicht und Sie diese aktualisieren möchten, ohne Rails und alles zu aktualisieren seine Abhängigkeiten. Führen Sie dazu bundle update nokogiri aus.
Bundler aktualisiert nokogiri und alle seine Abhängigkeiten, lässt jedoch Rails und seine Abhängigkeiten außer Acht.
Manchmal werden mehrere in Ihrer Gemfile(5) deklarierte Gems durch dieselbe Abhängigkeit der zweiten Ebene erfüllt. Betrachten Sie zum Beispiel den Fall von thin und rack-perftools-profiler.
source "https://rubygems.org"
gem "thin"
gem "rack-perftools-profiler"Der thin Gem hängt von rack >= 1.0 ab, während rack-perftools-profiler von rack ~> 1.0 abhängt . Wenn Sie die Bundle-Installation ausführen, erhalten Sie Folgendes:
Fetching source index for https://rubygems.org/
Installing daemons (1.1.0)
Installing eventmachine (0.12.10) with native extensions
Installing open4 (1.0.1)
Installing perftools.rb (0.4.7) with native extensions
Installing rack (1.2.1)
Installing rack-perftools_profiler (0.0.2)
Installing thin (1.2.7) with native extensions
Using bundler (1.0.0.rc.3)In diesem Fall haben die beiden Gems ihre eigenen Abhängigkeiten, aber sie teilen sich das Rack. Wenn Sie bundle update Thin ausführen, aktualisiert der Bundler Daemons, Eventmachine und Rack, die Abhängigkeiten von thin, aber nicht open4 oder perftools.rb, die Abhängigkeiten von rack-perftools_profiler sind. Beachten Sie, dass Bundle Update Thin Rack aktualisiert, obwohl es auch eine Abhängigkeit von rack-perftools_profiler ist.
Kurz gesagt: Wenn Sie ein Gem mit Bundle Update aktualisieren, aktualisiert der Bundler standardmäßig alle Abhängigkeiten dieses Gems, einschließlich derjenigen, die auch Abhängigkeiten eines anderen Gems sind.
Um die Aktualisierung indirekter Abhängigkeiten zu verhindern, war vor Version 1.14 die einzige Option das CONSERVATIVE UPDATING-Verhalten in bundle install(1) bundle-install.1.html:
In diesem Szenario führt die manuelle Aktualisierung der thin-Version in Gemfile(5) und die anschließende Ausführung von bundle install(1) bundle-install.1.html nur zu einer Aktualisierung von daemons und eventmachine, aber nicht rack. Weitere Informationen finden Sie im Abschnitt KONSERVATIVE AKTUALISIERUNG von bundle install(1) bundle-install.1.html.
Ab 1.14 verhindert die Angabe der Option --conservative auch, dass indirekte Abhängigkeiten aktualisiert werden.
Mit Version 1.14 wurden 4 Optionen auf Patch-Ebene eingeführt, die Einfluss darauf haben, wie Gem-Versionen aufgelöst werden. Eine der folgenden Optionen kann verwendet werden: --patch, --minor oder --major. --strict kann hinzugefügt werden, um die Auflösung weiter zu beeinflussen.
Aktualisieren Sie lieber nur auf die nächste Patch-Version.
Aktualisieren Sie lieber nur auf die nächste Nebenversion.
Bevorzugen Sie die Aktualisierung auf die nächste Hauptversion (Standard).
Lassen Sie nicht zu, dass Edelsteine nach dem neuesten --patch | aktualisiert werden --moll | --major.
Wenn Bundler auflöst, welche Versionen zur Erfüllung deklarierter Anforderungen in der Gemfile oder in übergeordneten Gems verwendet werden sollen, sucht es nach allen verfügbaren Versionen, filtert alle Versionen heraus, die die Anforderung nicht erfüllen, und sortiert sie dann standardmäßig von der neuesten bis zur neuesten am ältesten, wenn man sie in dieser Reihenfolge betrachtet.
Durch die Bereitstellung einer der Patch-Level-Optionen (z. B. --patch) wird die Sortierreihenfolge der zufriedenstellenden Versionen geändert, sodass Bundler den neuesten --patch oder - berücksichtigt. -Nebenversion vor anderen Versionen verfügbar. Beachten Sie, dass Versionen außerhalb des angegebenen Patch-Levels bei Bedarf dennoch aufgelöst werden können, um ein geeignetes Abhängigkeitsdiagramm zu finden.
Wenn beispielsweise Gem „foo“ auf 1.0.2 gesperrt ist, keine Gem-Anforderung in der Gemfile definiert ist und alle Versionen 1.0.3, 1.0.4, 1.1.0, 1.1.1 und 2.0.0 vorhanden sind, ist dies die Standardeinstellung Die Standardreihenfolge (--major) lautet „2.0.0, 1.1.1, 1.1.0, 1.0.4, 1.0.3, 1.0.2“.
Wenn die Option --patch verwendet wird, ändert sich die Präferenzreihenfolge in „1.0.4, 1.0.3, 1.0.2, 1.1.1, 1.1.0, 2.0.0“.
Wenn die Option --minor verwendet wird, ändert sich die Präferenzreihenfolge in „1.1.1, 1.1.0, 1.0.4, 1.0.3, 1.0.2, 2.0.0“.
Durch die Kombination der Option --strict mit einer der Patch-Level-Optionen werden alle Versionen entfernt, die über den Geltungsbereich der Patch-Level-Option hinausgehen, um sicherzustellen, dass kein Gem bis zu diesem Zeitpunkt aktualisiert wird.
Um das vorherige Beispiel fortzusetzen: Wenn sowohl die Optionen --patch als auch --strict verwendet werden, wären die verfügbaren Versionen für die Auflösung „1.0.4, 1.0.3, 1.0 .2". Wenn --minor und --strict verwendet werden, wäre es „1.1.1, 1.1.0, 1.0.4, 1.0.3, 1.0.2“.
Die im Gemfile definierten Gem-Anforderungen sind weiterhin der erste bestimmende Faktor dafür, welche Versionen verfügbar sind. Wenn die Gem-Anforderung für foo in der Gemfile „~> 1.0“ ist, wird damit dasselbe erreicht wie die Bereitstellung von --minor und --strict< Optionen.
Angesichts der folgenden Edelsteinspezifikationen:
foo 1.4.3, requires: ~> bar 2.0
foo 1.4.4, requires: ~> bar 2.0
foo 1.4.5, requires: ~> bar 2.1
foo 1.5.0, requires: ~> bar 2.1
foo 1.5.1, requires: ~> bar 3.0
bar with versions 2.0.3, 2.0.4, 2.1.0, 2.1.1, 3.0.0Gemfile:
gem 'foo'Gemfile.lock:
foo (1.4.3)
bar (~> 2.0)
bar (2.0.3)Fälle:
# Command Line Result
------------------------------------------------------------
1 bundle update --patch 'foo 1.4.5', 'bar 2.1.1'
2 bundle update --patch foo 'foo 1.4.5', 'bar 2.1.1'
3 bundle update --minor 'foo 1.5.1', 'bar 3.0.0'
4 bundle update --minor --strict 'foo 1.5.0', 'bar 2.1.1'
5 bundle update --patch --strict 'foo 1.4.4', 'bar 2.0.4'In Fall 1 wird bar auf 2.1.1 aktualisiert, eine geringfügige Versionserhöhung, da die Abhängigkeit von foo 1.4.5 dies erforderte.
In Fall 2 muss nur foo entsperrt werden, aber bar darf sich auch bewegen, da es sich nicht um eine deklarierte Abhängigkeit in der Gemfile handelt.
Im Fall 3 erhöht sich bar um eine ganze Hauptversion, da für foo jetzt eine geringfügige Erhöhung bevorzugt wird, und wenn es auf 1.5.1 geht, ist 3.0.0 von bar erforderlich.
Im Fall 4 wird foo bis zu einer Nebenversion bevorzugt, aber 1.5.1 funktioniert nicht, da das Flag --strict Bar 3.0.0 aus der Betrachtung entfernt, da es sich um eine größere Erweiterung handelt.
Im Fall 5 werden sowohl für foo als auch für bar alle kleineren oder größeren Inkremente aufgrund des Flags --strict aus der Betrachtung entfernt, sodass sie maximal bis zu 1.4.4 und 2.0.4 verschoben werden können.
Im Allgemeinen sollten Sie beim Arbeiten mit einer mit Bundler verwalteten Anwendung den folgenden Workflow verwenden:
Nachdem Sie Ihr Gemfile(5) zum ersten Mal erstellt haben, führen Sie es aus
bundle install
Überprüfen Sie die resultierende Gemfile.lock in die Versionskontrolle
git add Gemfile.lock
Wenn Sie dieses Repository auf einem anderen Entwicklungscomputer auschecken, führen Sie es aus
bundle install
Wenn Sie dieses Repository auf einem Bereitstellungscomputer auschecken, führen Sie Folgendes aus:
bundle install --deployment
Nachdem Sie Gemfile(5) geändert haben, um eine neue oder aktualisierte Abhängigkeit widerzuspiegeln, führen Sie Folgendes aus
bundle install
Stellen Sie sicher, dass Sie das aktualisierte Gemfile.lock in die Versionskontrolle einchecken
git add Gemfile.lock
Wenn bundle install(1) bundle-install.1.html einen Konflikt meldet, aktualisieren Sie manuell die spezifischen Gems, die Sie in der Gemfile(5) geändert haben.
bundle update rails thin
Wenn Sie alle Gems auf die neuesten möglichen Versionen aktualisieren möchten, die noch mit den in der Gemfile(5) aufgeführten Gems übereinstimmen, führen Sie Folgendes aus
bundle update --all