bundle install

bundle-install - Gemfileに指定された依存関係をインストールします

bundle install [--binstubs[=DIRECTORY]]
                 [--clean]
                 [--deployment]
                 [--frozen]
                 [--full-index]
                 [--gemfile=GEMFILE]
                 [--jobs=NUMBER]
                 [--local]
                 [--no-cache]
                 [--no-prune]
                 [--path PATH]
                 [--prefer-local]
                 [--quiet]
                 [--redownload]
                 [--retry=NUMBER]
                 [--shebang]
                 [--standalone[=GROUP[ GROUP...]]]
                 [--system]
                 [--trust-policy=POLICY]
                 [--with=GROUP[ GROUP...]]
                 [--without=GROUP[ GROUP...]]

説明

Gemfile(Gemfile(5))に指定されたgemをインストールします。初めてbundle installを実行する場合（Gemfile.lockが存在しない場合）、Bundlerはすべてのリモートソースを取得し、依存関係を解決して、必要なすべてのgemをインストールします。

Gemfile.lockが存在し、Gemfile(5)を更新していない場合、Bundlerはすべてのリモートソースを取得しますが、依存関係の解決にはGemfile.lockに指定された依存関係を使用します。

Gemfile.lockが存在し、Gemfile(5)を更新した場合、Bundlerは更新していないgemについてはGemfile.lockの依存関係を使用しますが、更新したgemの依存関係は再解決します。この更新プロセスに関する詳細については、下記のCONSERVATIVE UPDATINGを参照してください。

オプション

--clean、--deployment、--frozen、--no-prune、--path、--shebang、--system、--without、--withオプションは非推奨です。これらのオプションは、後続のすべてのbundle install実行に自動的に適用される場合にのみ意味があり、そのためにはbundlerがそれらを暗黙的に記憶する必要があります。将来のバージョンのbundlerではCLIフラグを記憶しなくなるため、永続的に適用するにはbundle config（bundle-config(1)を参照）を使用する必要があります。

--binstubs[=<directory>]

ビンスタブは、実行可能ファイルをラップするスクリプトです。Bundlerは、Bundlerをロードし、コマンドを実行する小さなRubyファイル（ビンスタブ）を作成し、bin/に配置します。これにより、アプリケーション内のビンスタブを、アプリケーションに必要なgemの正確なバージョンにリンクできます。

(デフォルトは~/bin)ディレクトリを作成し、gemの実行可能ファイルをそこに配置します。これらの実行可能ファイルは、Bundlerのコンテキストで実行されます。使用する場合、このディレクトリを環境のPATH変数に追加する必要があるかもしれません。例えば、rails gemにrails実行可能ファイルが含まれている場合、このフラグはbin/rails実行可能ファイルを作成し、参照されるすべての依存関係がバンドルされたgemを使用して解決されるようにします。

--clean

インストールが完了すると、Bundlerは現在のGemfile(5)に存在しないgemを削除します。現在使用中のgemは削除されませんのでご安心ください。

このオプションは、clean設定に置き換えられました。

--deployment

デプロイメントモードでは、Bundlerは本番環境またはCI使用のためにバンドルを「ロールアウト」します。開発環境でこのオプションを有効にするかどうかを慎重に確認してください。

このオプションは、deployment設定に置き換えられました。

--redownload

必要なバージョンがローカルに既に存在していても、すべてのgemを強制的にダウンロードします。

--frozen

このインストール後にGemfile.lockが更新されないようにします。Gemfile.lockに変更がある場合は、非ゼロで終了します。

このオプションは、frozen設定に置き換えられました。

--full-index

BundlerはRubygemsのAPIエンドポイントを呼び出しませんが（デフォルト）、すべてのgemの（現在は大規模な）インデックスファイルをダウンロードしてキャッシュします。このオプションを有効にすることで、ほとんど変更されない大規模なバンドルのパフォーマンスを向上させることができます。

--gemfile=<gemfile>

Bundlerが使用するGemfile(5)の場所です。デフォルトでは、現在の作業ディレクトリのGemfile(5)になります。一般的に、BundlerはGemfile(5)の場所がプロジェクトのルートでもあると想定し、この場所を基準にGemfile.lockとvendor/cacheを探します。

--jobs=[<number>]、-j[<number>]

並列ダウンロードとインストールジョブの最大数です。デフォルトは使用可能なプロセッサの数です。

--local

rubygems.orgへの接続を試みません。代わりに、BundlerはRubygemsのキャッシュまたはvendor/cacheに既に存在するgemを使用します。適切なプラットフォーム固有のgemがrubygems.orgに存在する場合、見つからないことに注意してください。

--prefer-local

解決時に、ローカルにインストールされているgem、またはRubygemsのキャッシュやvendor/cacheに既に存在するgemを強制的に使用します。リモートで新しいバージョンが利用可能な場合でも同様です。ローカルに存在しないgemについては、rubygems.orgへの接続のみ試みます。

--no-cache

新しくバンドルされたgemでvendor/cacheのキャッシュを更新しません。キャッシュ内のgemは削除されませんが、新しくバンドルされたgemはインストール中にキャッシュされません。

--no-prune

インストールが完了したときに、キャッシュから古いgemを削除しません。

このオプションは、no_prune設定に置き換えられました。

--path=<path>

指定されたgemをインストールする場所です。デフォルトはRubygemsの設定です。BundlerはRubygemsとこの場所を共有します。gem install ...もgemをそこにインストールします。したがって、--path ...設定なしでインストールされたgemは、gem listを呼び出すことで表示されます。それに応じて、他の場所にインストールされたgemは一覧表示されません。

このオプションは、path設定に置き換えられました。

--quiet

標準出力に進行状況情報を表示しません。代わりに、Bundlerはステータスコード（$?）を使用して終了します。

--retry=[<number>]

失敗したネットワーク要求またはgit要求をnumber回再試行します。

--shebang=<ruby-executable>

--binstubsで作成されたスクリプトを実行するために、指定されたruby実行可能ファイル（通常はruby）を使用します。さらに、--binstubsと--shebang jrubyを一緒に使用すると、これらの実行可能ファイルはjrubyを実行するように変更されます。

このオプションは、shebang設定に置き換えられました。

--standalone[=<list>]

実行時にRubygemsまたはBundlerに依存せずに動作するバンドルを作成します。インストールするグループのスペース区切りのリストを指定する必要があります。Bundlerはbundleという名前のディレクトリを作成し、そこにバンドルをインストールします。また、Bundler独自のセットアップを必要な方法で置き換えるbundle/bundler/setup.rbファイルも生成します。このオプションを使用すると、暗黙的にpathが設定されます。これは[記憶されたオプション][REMEMBERED OPTIONS]です。

--system

バンドルに指定されたgemをシステムのRubygemsの場所にインストールします。これにより、以前の--pathの設定が上書きされます。

このオプションは、system設定に置き換えられました。

--trust-policy=[<policy>]

Rubygemsセキュリティポリシーpolicyを適用します。ここでpolicyは、HighSecurity、MediumSecurity、LowSecurity、AlmostNoSecurity、NoSecurityのいずれかです。詳細については、下記のSEE ALSOにあるRubygems署名ドキュメントを参照してください。

--with=<list>

インストールするgemを参照するグループのスペース区切りのリストです。オプションのグループが指定されている場合、インストールされます。--withoutに与えられたグループが記憶されているグループのリストにある場合、そのリストから削除されます。

このオプションは、with設定に置き換えられました。

--without=<list>

インストール中にスキップするgemを参照するグループのスペース区切りのリストです。--withに与えられたグループが記憶されているグループのリストにある場合、そのリストから削除されます。

このオプションは、without設定に置き換えられました。

デプロイメントモード

Bundlerのデフォルトは開発用に最適化されています。デプロイメントとCI用に最適化されたデフォルトに切り替えるには、--deploymentフラグを使用します。開発マシンではデプロイメントモードを有効にしないでください。 Gemfile(5)が変更されるとエラーが発生します。

1. Gemfile.lockが必要です。

   開発時とテストで使用したgemの同じバージョンをデプロイメントでも使用するには、Gemfile.lockが必要です。

   これは主に、Gemfile.lockをバージョン管理にチェックインすることを忘れないようにするためです。

2. Gemfile.lockは最新である必要があります

   開発では、Gemfile(5)を変更し、bundle installを再実行して、Gemfile.lockのスナップショットを保守的に更新できます。

   デプロイメントでは、Gemfile.lockはGemfile(5)で行われた変更と最新である必要があります。

3. gemは、デフォルトのシステムの場所ではなくvendor/bundleにインストールされます

   開発では、アプリケーションで使用されるgemを他のアプリケーションやシステムで実行される他のスクリプトと共有すると便利です。

   デプロイメントでは、分離がより重要なデフォルトです。さらに、アプリケーションをデプロイするユーザーがシステムにgemをインストールする権限を持っていない場合、またはWebサーバーがgemを読み取る権限を持っていない場合があります。

   その結果、bundle install --deploymentは、アプリケーションのvendor/bundleディレクトリにgemをインストールします。これは--pathオプションを使用して上書きできます。

グループのインストール

デフォルトでは、bundle installはGemfile(5)のすべてのグループのすべてのgemをインストールしますが、異なるプラットフォーム用に宣言されたgemを除きます。

ただし、--withoutオプションを使用して、特定のグループのインストールをスキップするようにBundlerに明示的に指示できます。このオプションは、スペースで区切られたグループのリストを取ります。

--withoutオプションは指定されたグループのgemのインストールをスキップしますが、それらのgemをダウンロードし、Gemfile(5)のすべてのgemの依存関係を解決するために使用します。

これは、別のマシン（本番サーバーなど）で異なるグループのセットをインストールしても、既に開発およびテスト済みのgemとバージョンが変更されないようにするためです。

Bundlerは、開発とテストで実行しているサードパーティのコードが、本番でも実行しているサードパーティのコードと確実に一致することを保証します。異なる環境で一部のコードを除外することはできますが、異なる環境で異なるバージョンのサードパーティコードが使用されるという事態には決してなりません。

簡単な例として、次のGemfile(5)を考えてみましょう。

source 'https://rubygems.org'

gem 'sinatra'

group :production do
  gem 'rack-perftools-profiler'
end

この場合、sinatraはRackの任意のバージョン（>= 1.0）に依存し、rack-perftools-profilerは1.x（~> 1.0）に依存します。

開発環境でbundle install --without productionを実行すると、rack-perftools-profilerの依存関係も考慮されます。これにより、Rack 2.0に対応した新しいAPIを使って開発を進め、Rack 1.xでは利用できない機能を利用したにも関わらず、productionグループが使用された際にBundlerがRack 1.2に切り替わる、といった事態を防ぎます。

実際には、除外されたグループのgemをインストールしようとはしないため、依存関係の解決プロセスの一環として評価するのみであり、問題が発生することはありません。

これはまた、同じgemの異なるバージョンを異なるグループに含めることができないことを意味します。なぜなら、そうすると開発環境と本番環境で異なる依存関係セットが使用されることになるからです。依存関係の解決プロセスの複雑さから、これは通常、GemfileGemfile(5)にリストされているgem以上に影響し、（驚くべきことに）使用しているgemを根本的に変更する可能性があります。

Gemfile.lock

bundle installを実行すると、Bundlerは使用したすべてのgemの完全な名前とバージョン（GemfileGemfile(5)に指定されたgemの依存関係を含む）をGemfile.lockというファイルに保存します。

Bundlerは、後続のbundle install呼び出しでこのファイルを使用します。これにより、アプリケーションがマシン間を移動しても、常に同じコードを使用することが保証されます。

依存関係の解決方法のため、一見小さな変更（たとえば、GemfileGemfile(5)のgemの依存関係のポイントリリースの更新）でも、すべての依存関係を満たすために必要なgemが根本的に異なる場合があります。

その結果、アプリケーションとgemの両方でGemfile.lockをバージョン管理システムにコミットする必要があります。 そうしないと、リポジトリをチェックアウトするすべてのマシン（本番サーバーを含む）がすべての依存関係を再度解決し、GemfileGemfile(5)のgemまたはその依存関係のいずれかが更新されている場合、異なるバージョンのサードパーティコードが使用されることになります。

Bundlerが最初にリリースされたとき、Gemfile.lockは生成されたgemに含まれる.gitignoreファイルに含まれていました。しかし、時間の経過とともに、この方法では依存関係の破損の問題が新しい貢献者に押し付けられ、既存の貢献者はその問題に気付かない可能性があることが明らかになりました。bundle installは通常、貢献への最初のステップであるため、依存関係の破損の問題は、新しい貢献者が貢献することを妨げます。そのため、gem作成者向けのガイドラインを改訂し、gemのlockファイルをコミットすることを推奨しています。

保守的な更新

GemfileGemfile(5)に変更を加えてからbundle installを実行すると、Bundlerは変更したgemのみを更新します。

言い換えれば、bundle installを呼び出す前に変更しなかったgemが動作していた場合、更新後も以前と同じ依存関係のバージョンを引き続き使用します。

例を見てみましょう。元のGemfileGemfile(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はGemfileGemfile(5)の両方のgemの要件を満たすactivesupport 2.3.8を選択します。

次に、GemfileGemfile(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は変更していないことに気付きます。Bundlerは、その要件を満たすために現在使用されているgemを評価します。

activesupport 2.3.8

これは、更新されていないactivemerchantの依存関係を満たすためにも使用されています。

rack ~> 1.1.0

これは、他の依存関係を満たすために現在使用されていません。

activemerchantを明示的に更新するように要求していないため、actionpackを更新した後に突然動作しなくなることは期待しません。しかし、actionpackの新しいactivesupport 3.0.0.rc依存関係を満たすには、その依存関係の1つを更新する必要があります。

activemerchantは理論的にはactivesupport 3.0.0.rcに一致する非常に緩い依存関係を宣言していますが、Bundlerは変更されていないGemfileGemfile(5)のgemとその依存関係をアトミック単位として扱います。この場合、activemerchantの依存関係はactivemerchant 1.7.1 + activesupport 2.3.8として扱われるため、bundle installはactionpackを更新できないと報告します。

actionpackを明示的に更新するには、GemfileGemfile(5)の他のgemがまだ依存している依存関係を含めて、bundle update actionpackを実行します（bundle update(1)を参照）。

要約：一般的に、GemfileGemfile(5)に変更を加えた後は、最初にbundle installを実行して、GemfileGemfile(5)の他のgemが変更の影響を受けないことを確認してください。それが機能しない場合は、bundle update(1)を実行します。

参照

• gemインストールに関するドキュメント
• Rubygems署名に関するドキュメント