bundle-update - 利用可能な最新バージョンにgemをアップデートします
bundle update *gems [--all]
[--group=NAME]
[--source=NAME]
[--local]
[--ruby]
[--bundler[=VERSION]]
[--full-index]
[--jobs=JOBS]
[--quiet]
[--patch|--minor|--major]
[--redownload]
[--strict]
[--conservative]指定されたgem（--allフラグが使用されている場合はすべてのgem）をアップデートします。Gemfile.lockに指定されている以前にインストールされたgemは無視されます。一般的には、bundle install(1)を使用して、マシン間で全く同じgemとバージョンをインストールする必要があります。
gemのバージョンを明示的にアップデートする場合は、bundle updateを使用します。
--all--group=<name>, -g=[<name>]bundle update --group developmentで開発グループ内のすべてのgemをアップデートできます。また、例えば、bundle update rails --group testでrails gemとテストグループ内のすべてのgemをアップデートすることもできます。--source=<name>:gitまたは:pathソースの名前です。例えば、http://github.com/rails/rails.gitの:gitソースの場合、bundle update --source railsと呼び出します。--local--ruby--bundler--full-index--jobs=[<number>], -j[<number>]--retry=[<number>]--quiet--redownload--patch--minor--major--strict--patch | --minor | --majorを超えてgemをアップデートすることを許可しません。--conservativebundle update --allを実行すると、Bundlerは以前にインストールされたgemを無視し、ソースで使用可能なすべてのgemの最新バージョンに基づいて、すべての依存関係を再度解決します。
次のGemfile(5)を考慮してください
source "https://rubygems.org"
gem "rails", "3.0.0.rc"
gem "nokogiri"
最初にbundle install(1)を実行すると、Bundlerはすべての依存関係を最後まで解決し、必要なものをインストールします。
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.
ご覧のとおり、Gemfile(5)に2つのgemがある場合でも、アプリケーションの実行には26個の異なるgemが必要です。Bundlerはインストールした正確なバージョンをGemfile.lockに記憶します。次にbundle install(1)を実行すると、Bundlerは依存関係の解決をスキップし、前回インストールしたのと同じgemをインストールします。
Gemfile.lockをバージョン管理にチェックインし、別のマシンでクローンした後、bundle install(1)を実行しても、前回インストールしたgemがインストールされます。erubisやmailの新しいリリースによって使用するgemが変更されることを心配する必要はありません。
ただし、時折、Gemfile(5)のgemと依然として一致する最新のバージョンに使用するgemをアップデートすることが必要な場合があります。
これを行うには、bundle update --allを実行します。これにより、Gemfile.lockが無視され、すべての依存関係が再度解決されます。このプロセスにより、gemの作者が前回bundle update --allを実行して以来リリースした新しいgemの要件に基づいて、25個のgemのセットが大幅に異なる可能性があることに注意してください。
場合によっては、Gemfile(5)内の単一のgemをアップデートし、指定した他のgemはGemfile.lock内のバージョンにロックしたままにしておくことが必要な場合があります。
例えば、上記のシナリオで、nokogiriがバージョン1.4.4をリリースし、Railsとそのすべての依存関係をアップデートせずにアップデートしたいとします。これを行うには、bundle update nokogiriを実行します。
Bundlerはnokogiriとその依存関係をアップデートしますが、Railsとその依存関係はそのままにします。
場合によっては、Gemfile(5)で宣言されている複数のgemが、同じ2次レベルの依存関係によって満たされます。例えば、thinとrack-perftools-profilerの場合を考えてみましょう。
source "https://rubygems.org"
gem "thin"
gem "rack-perftools-profiler"
thin gemはrack >= 1.0に依存しますが、rack-perftools-profilerはrack ~> 1.0に依存します。bundle installを実行すると、次のようになります。
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)
この場合、2つのgemにはそれぞれ依存関係のセットがありますが、共通してrackを共有しています。bundle update thinを実行すると、Bundlerはthinの依存関係であるdaemons、eventmachine、rackをアップデートしますが、rack-perftools_profilerの依存関係であるopen4やperftools.rbはアップデートしません。rackはrack-perftools_profilerの依存関係でもあるにもかかわらず、bundle update thinによってアップデートされることに注意してください。
つまり、デフォルトでは、bundle updateを使用してgemをアップデートすると、Bundlerは、別のgemの依存関係でもあるものを含め、そのgemのすべての依存関係をアップデートします。
バージョン1.14より前では、間接的な依存関係のアップデートを防ぐ唯一の方法は、bundle install(1)のCONSERVATIVE UPDATING動作でした。
このシナリオでは、Gemfile(5)でthinのバージョンを手動でアップデートし、bundle install(1)を実行すると、rackではなくdaemonsとeventmachineのみがアップデートされます。詳細については、bundle install(1)のCONSERVATIVE UPDATINGセクションを参照してください。
1.14以降、--conservativeオプションを指定すると、間接的な依存関係のアップデートも防止されます。
バージョン1.14では、gemのバージョンの解決方法に影響を与える4つのパッチレベルオプションが導入されました。次のオプションのいずれかを使用できます。--patch、--minor、--major。--strictを追加して、解決にさらに影響を与えることができます。
--patch--minor--major--strict--patch | --minor | --majorを超えてgemをアップデートすることを許可しません。Bundlerは、Gemfileまたは親gemで宣言された要件を満たすために使用するバージョンを解決する場合、使用可能なすべてのバージョンを調べ、要件を満たさないバージョンをフィルタリングし、デフォルトでは、それらを最新から最古の順にソートし、その順序で考慮します。
パッチレベルオプションの1つ（例：--patch）を提供すると、満たすバージョンのソート順序が変更され、Bundlerは他のバージョンよりも先に使用可能な最新の--patchまたは--minorバージョンを考慮するようになります。適切な依存関係グラフを見つけるために必要な場合、指定されたパッチレベル外のバージョンが依然として解決される可能性があることに注意してください。
例えば、gem 'foo'が1.0.2でロックされており、Gemfileにgemの要件が定義されておらず、バージョン1.0.3、1.0.4、1.1.0、1.1.1、2.0.0が存在する場合、デフォルトの優先順位（--major）は「2.0.0、1.1.1、1.1.0、1.0.4、1.0.3、1.0.2」になります。
--patchオプションを使用すると、優先順位は「1.0.4、1.0.3、1.0.2、1.1.1、1.1.0、2.0.0」に変更されます。
--minorオプションを使用すると、優先順位は「1.1.1、1.1.0、1.0.4、1.0.3、1.0.2、2.0.0」に変更されます。
パッチレベルオプションのいずれかと--strictオプションを組み合わせると、パッチレベルオプションの範囲を超えるバージョンが削除され、gemがそこまでアップデートされないことが保証されます。
前の例を続ける場合、--patchと--strictの両方のオプションを使用すると、解決に使用可能なバージョンは「1.0.4、1.0.3、1.0.2」になります。--minorと--strictを使用すると、「1.1.1、1.1.0、1.0.4、1.0.3、1.0.2」になります。
Gemfileで定義されているgemの要件は、依然として使用可能なバージョンを決定する最初の要素です。Gemfileのfooのgem要件が'~> 1.0'の場合、それは--minorと--strictのオプションを提供することと同じことを行います。
次のgemの仕様を想定します
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.0
Gemfile
gem 'foo'
Gemfile.lock
foo (1.4.3)
bar (~> 2.0)
bar (2.0.3)
ケース
# 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'
ケース1では、foo 1.4.5からの依存関係によって、barはマイナーバージョンの増加である2.1.1にアップグレードされます。
ケース2では、fooのみのロック解除が要求されますが、barはGemfileに宣言された依存関係ではないため、移動も許可されます。
ケース3では、fooでマイナーの増加が優先されるようになったため、barはメジャーリリース全体にアップグレードされます。そして、1.5.1になると、barの3.0.0が必要になります。
ケース4では、fooはマイナーバージョンまで優先されますが、1.5.1は機能しません。なぜなら、--strictフラグによって、メジャーの増分であるためbar 3.0.0が考慮から除外されるためです。
ケース5では、--strictフラグのために、fooとbarの両方でマイナーまたはメジャーの増分が考慮から除外されるため、最大で1.4.4と2.0.4までしか移動できません。
一般的に、Bundlerで管理されているアプリケーションを使用する場合は、次のワークフローを使用する必要があります。
最初にGemfile(5)を作成した後、実行します。
$ bundle install
結果のGemfile.lockをバージョン管理にチェックインします。
$ git add Gemfile.lock
別の開発マシンでこのリポジトリをチェックアウトする際、実行します。
$ bundle install
デプロイマシンでこのリポジトリをチェックアウトする際、実行します。
$ bundle install --deployment
Gemfile(5)を変更して新しい依存関係または更新された依存関係を反映した後、実行します。
$ bundle install
更新されたGemfile.lockをバージョン管理にチェックインすることを確認してください。
$ git add Gemfile.lock
bundle install(1)が競合を報告した場合、Gemfile(5)で変更した特定のgemを手動でアップデートします。
$ bundle update rails thin
GemfileGemfile(5)に記載されているgemと互換性のある、最新のバージョンに全てのgemをアップデートしたい場合は、以下のコマンドを実行してください。
$ bundle update --all