Updating a Dependency
もちろん、ある時点で、アプリケーションが依存している特定の依存性のバージョンを更新したいと思うかもしれません。 例えば、rails を 3.0.0 final に更新したいと思うかもしれません。 重要なのは、ある依存関係を更新したからといって、すべての依存関係を再解決し、すべての最新バージョンを使いたいとは限らないということです。 この例では、3 つの依存関係しかありませんが、この場合でも、すべてを更新すると複雑になります。
例示すると、rails 3.0.0.rc gem は actionpack 3.0.0.rc gem に依存しており、それは rack ~> 1.2.1 に依存しています (これは >= 1.2.1 と ). The rack-cache gem は rack >= 0.4 に依存しているということです)。 rails 3.0.0 最終版の gem も rack ~> 1.2.1 に依存しており、rails 3.0.0 のリリース以降に Rack チームが rack 1.2.2 をリリースしたと仮定しましょう。
Railsをアップデートするためにナイーブにすべての gem をアップデートすると、rails 3.0.0 と rack-cache の両方の要件を満たす rack 1.2.2 を取得することができるのです。 しかし、特に rack-cache のアップデートを要求していないため、rack 1.2.2 と互換性がない可能性があります (理由はどうあれ)。 また、rack 1.2.1 から rack 1.2.2 への更新はおそらく何も壊さないでしょうが、より大きなジャンプを伴う同様のシナリオが起こり得ます。 (詳細については、以下を参照してください)
この問題を回避するために、gem を更新するとき、bundler はその gem の依存関係を更新せず、他の gem がまだそれに依存している場合、その gem を更新します。 この例では、rack-cache はまだ rack に依存しているので、bundler は rack gem をアップデートしません。 これにより、rails を更新しても rack-cache が不意に壊れることはありません。 rails 3.0.0 の依存関係 actionpack 3.0.0 は rack 1.2.1 と互換性があるので、bundler はそれをそのままにし、rack-cache は rack 1.2.2 との非互換性に直面しても動作しつづけます。
最初に rails 3.0.0.rc への依存を宣言したので、rails 3.0.0 に更新したい場合は、単に Gemfile を gem 'rails', '3.0.0' に更新して次のように実行します:
$ bundle install 前述のように、bundle install コマンドは常に保守的に更新を行い、Gemfile で明確に変更されていない gem (やその依存) は更新しないことにしています。 つまり、Gemfile で rack-cache を変更しなかった場合、bundler はそれを ** およびその依存関係** (rack) を単一の、変更できないユニットとして扱います。 rails 3.0.0 が rack-cache と互換性がない場合、bundler はスナップショットされた依存関係 (Gemfile.lock) と更新された Gemfile との間の競合を報告します。
Gemfile を更新し、システムがすでにすべての依存関係を持つ場合、アプリケーション起動時に bundler が Gemfile.lock を透過的に更新します。 たとえば、mysql を Gemfile に追加し、すでにシステムにインストールされている場合、bundle install を実行せずにアプリケーションを起動でき、bundler は “last known good” 設定を Gemfile.lock スナップショットに持続させます。 重要な依存関係を持つ gems (rails) や、多くの gems が依存しているもの (rack) を更新する場合は、おそらく失敗します。 透過的な更新に失敗すると、アプリケーションの起動に失敗し、bundler は bundle install.
を実行するように指示するエラーを出力します。