bundle install
Gemfile内で指定された依存性のインストールを行います。
文法
bundle install [--gemfile=GEMFILE] [--path PATH] [--system]
[--without=GROUP1[ GROUP2...]] [--local]
[--deployment] [--binstubs[=DIRECTORY]]
[--standalone[=GROUP1[ GROUP2...]]]
[--trust-policy=POLICY] [--jobs=SIZE]
[--retry=TRIES] [--no-cache] [--quiet]
[--clean] [--full-index] [--no-prune] [--shebang]
説明
Gemfile(5)に指定されたGemをインストールします。
もし、初めてのbundle install(そして、Gemfile.lockが無ければ)の実行であれば、
Bundlerは全てのリモートの供給元からGemを取得し、依存関係を解決して、必要なGemをインストールします。
もし、Gemfile.lockが存在し、Gemfile(5)が更新されていないのであれば、
Bunlderはリモートの供給元からGemを取得しますが、依存性の解決を行うのでは無く、
Gemfile.lockに指定されている依存性を使用します。
もし、Gemfile.lockが存在し、Gemfile(5)が更新されているのであれば、
BUndlerは更新されていないGemに対しては、Gemfile.lock内の依存性を使用しますが、
更新されたGemに対しては依存性の再解決を行います。
この更新処理についてより詳しく知りたければ、「保守的な更新」以降を参照してください。
オプション
デプロイ(--deployment)モード
Bundlerはデフォルトで、開発環境用に最適化されています。
デフォルトをデプロイ用の最適化に切り替えるには、--deploymentフラグを使用します。
Gemfileが編集された際にエラーを引き起こすため、
開発用のマシン上でdeploymentモードを作動させないでください。
-
Gemfile.lockは必須であること。あなたが開発とテストを行ったGemと同じバージョンが、デプロイでも使用されることを保証するために、
Gemfile.lockが必須となります。これを保証するために、バージョン管理システムへ
Gemfile.lockをチェックインすることを忘れないようにしてください。 -
Gemfile.lockは最新であること。
開発環境では、Gemfile(5)を修正し、 Gemfile.lockのスナップショットを保守的に更新するために、
bundle installを再実行することが出来ます。開発環境では、Gemfile(5)の変更に伴い、 Gemfile.lockも最新になるべきです。
-
Gemは、デフォルトのシステム(system)のロケーション(場所)ではなく、
vendor/bundleへインストールされるべきです。開発環境では、Gemは複数のアプリケーション、システム上で実行されるその他のスクリプトで共有されると便利です。
デプロイ環境では、デフォルトでそれが独立している事が重要になります。 更に、ユーザーによるアプリケーションのデプロイでは、そのシステムへのGemのインストール権限が無いかもしれません。 また、Webサーバーがそれらを読み込み権限がない可能性もあります。
結果的に
bundle install --deploymentは、 アプリケーション内のvendor/bundleディレクトリにGemをインストールします。 これは--pathオプションを使用して、上書きすることも出来ます。
sudoの取り扱い
デフォルトでは、Bundlerはgem installと同じ場所にGemをインストールします。
あるケースでは、その場所にはあなたのユーザー権限では上書き出来ないかもしれません。
そのようなケースでは、Bundlerは一時ディレクトリに全てを展開し、
次にシステムのロケーションにGemをコピーするために、
sudoのパスワードを訪ねてきます。
あなたの観点から見れば、これはシステムに直接Gemをインストールしたことと同じ事になります。
その他の幾つかのbundle installのステップでは、現在のユーザーとして実行されなければならないため、
sudo bundle installは使用するべきではありません。
-
Gemfile.lockの更新 -
必要な場合、
vendor/cacheの更新 - あなたのユーザーのSSHキーを使用したプライベートなGitリポジトリのチェックアウト
これら3つのうち、最初の2つは理屈としては、ファイルが結果的に$SUDO_USERにchownされることで処理することが可能です。
ただし3つ目に関しては、現在のユーザーとしてgitコマンドを実行することでしか、処理することは出来ません。
そのためgitのGemはダウンロードされ、$GEM_HOMEまたは$BUNDLE_PATHでは無く、
~/.bundle内にインストールされます。
結果的に、あなたは現在のユーザーとしてbundle installを実行するべきであり、
BundlerはGemを最終的な場所に配置する際にパスワードが必要になれば、それをあなたに尋ねてきます。
インストールグループ
デフォルトでbundle installは、異なるプラットフォーム向けに宣言されたものを除き、
Gemfile(5)内の全てのグループの全てのGemをインストールします。
ただし、--withoutオプションを使用することで、
インストールをスキップするグループをBundlerに伝えることが可能です。
このオプションは、空白区切りのグループのリストを受け取ります。
--withoutオプションは指定されたグループ内のGemのインストールをスキップする一方、
それらのGemのダウンロードは依然として行われ、Gemfile(5)内の各Gemの依存性の解決に使用されます。
そのため、別のマシン(productionサーバーのような)上でインストールされる異なるグループのGemとバージョンのセットが、 既に開発とテストを行ったものと異なるというような事はありません。
Bunlderは、開発とテスト環境上で実行したサードパーティーのコードが、 製品(produciton)環境上でも実行されることを固く(rock-solid)保証します。 異なる環境下で取り除くコードを選択することが出来ますが、 異なる環境下で使用されるサードパーティのコードのバージョンが異なることによって、 酷い状態に陥るということはありません。
簡単な例として、下記のGemfile(5)を確認して下さい。
source "https://rubygems.org"
gem "sinatra"
group :production do
gem "rack-perftools-profiler"
end
このケースではsinatraはRackのあるバージョンに依存します。
(rack-perftools-profilerが1.x (~> 1.0)に依存する間、>= 1.0)
開発環境下で、bundle install --without productionを実行した場合でも、
同様にrack-perftools-profilerの依存性を目にすることになります。
そうすることで、Rack 1.xでは使用出来ないRack 2.0の新しいAPIを使用して開発を行ってしまい、
時間を浪費するといったことを無くし、
製品(production)環境を使用する際には、BundlerをRack 1.2に切り替えるだけで良いことになります。
これは、異なるグループで同じGemの異なるバージョンを含めることは出来ないことを意味します。 そういった事が出来てしまうと、開発環境と製品環境で使用される依存性のセットが異なるといった結果になりかねません。 依存関係の解決プロセスの不意の変更によって、 Gemfile(5)内のリストに挙げられているGemだけでは無く、それ以上の多くのものに影響し、 使用中のGemの(驚くほど)抜本的な変更が行われる可能性があります。
記憶されるオプション
一部のオプション(「オプション」のセクション内で前述)は、
bundle installの呼び出し中にBundlerの実行によって記憶されます。
例えば、もしbundle install --without testを実行すると、
その後に続く--withoutを含まないbundle installの呼び出しは、
それ以前の選択を記憶します。
更にBundler.setupの呼び出しは、それらがインストールされていないものとして、
Rubyのloadパス上でそれらのグループで利用されるGemの作成を試みません。(翻訳に自信なし)
記憶される設定は下記の通りです。
Gemfile.lock
bundle installの実行時に、
Bundlerは使用される全てのGemのフルネームとバージョン(Gemfile(5)内に指定されたGemの依存性を含む)を、
Gemfile.lockと呼ばれるファイルに書き込みます。
Bundlerはこれ以降の全てのbundle installの呼び出しでこのファイルを使用することで、
アプリケーションが異なるマシンを跨いだとしても、常に同じコードが使用されることを保証します。
そのような方法で依存性の解決が動作するため、 外見上は小さな変更であったとしても(例えば、Gemfile(5)内のGemの依存性のポイントリリースの更新)、 全ての依存性を満たすのに必要とされるGemが、結果的に根本的に異なるGemになるというような可能性があります。
その結果、バージョンの管理はGemfile.lockを確認するべきです。
それを行わないと、リポジトリからチェックアウトを行った各マシン(製品版サーバーを含む)は、
全ての依存性の解決を再び行うことになり、もしGemfile(5)内の一部のGem、
またはそれらの一部の依存性が更新されると、サードパーティの異なるバージョンのコードが使用される結果を招きかねません。
保守的な更新
Gemfile(5)を変更してbundle installを実行すると、
Bundlerはあなたが変更を行ったGemだけを更新します。
言い換えると、bundle install呼び出し前に変更されなかったGemは、
更新される前に使用されていた全ての依存性が、全く同じバージョンで使用が継続されるということになります。
例を見てみましょう。ここに元となるGemfile(5)があるとします。
source "https://rubygems.org"
gem "actionpack", "2.3.8"
gem "activemerchant"
このケースでは、actionpackとactivemerchantの両方が、
activesupportに依存しています。
actionpackのGemは、activesupport 2.3.8とrack ~> 1.1.0に依存し、
一方activemerchantのGemは、
activesupport >= 2.3.2、braintree >= 2.0.0,、builder >= 2.0.0に依存します。
最初の依存性を解決すると、
BundlerはGemfile(5)内の両方の要件を満たすactivesupport 2.3.8を選択します。
次にあなたはGemfile(5)を次のように編集したとします。
source "https://rubygems.org"
gem "actionpack", "3.0.0.rc"
gem "activemerchant"
actionpack 3.0.0.rcのGemは新しい多数の依存性を持ち、
activesupportの依存性を= 3.0.0.rcへ、
またrackの依存性を~> 1.2.1へ更新します。
bundle installを実行すると、
BundlerはあなたがactionpackのGemを変更したことに注意を払いますが、
activemerchantのGemには注意を払いません。
現在の要件を満たすGemを次のように評価します。
activemerchantの更新を明確に求めていないことから、
あなたはactionpackの更新の後に、突然動作しなくなるとは思わないでしょう。
しかしながら、actionpackの新しい依存性となるactivesupport 3.0.0.rcを満たすには、
その依存性の1つを更新することを必要とします。
activemerchantは、理屈上ではactivesupport 3.0.0.rcにマッチするとてもルーズな依存性の宣言をしていますが、
BundlerはGemfile(5)内のGemを、依存性と共に非常に細かい単位で変更されていないものとして扱います。
このケースでは、activemerchantの依存性はactivemerchant 1.7.1 + activesupport 2.3.8として扱われるため、
bundle installはactionpackの更新が出来ないことを報告します。
actionpackを明確に更新するために、
Gemfile(5)内の他のGemにまだ依存している依存関係を含め、
bundle update actionpackを実行します。(bundle update(1)を参照)
要約: 一般的にはGemfile(5)の変更後には、
Gemfile(5)内の他のGemが変更によって影響(衝突?)を受けないことを確かめるために、
まずbundle installを試すべきです。
もしそれが動作しなければ、bundle update(1)を実行シて下さい。
参照
- Gem install docs: http://guides.rubygems.org/rubygems-basics/#installing-gems
- Rubygems signing docs: http://guides.rubygems.org/security/
© 2010 - 2017 STUDIO KINGDOM