Gemfile
- Rubyプログラムのgem依存関係を記述するための形式
A Gemfile
describes the gem dependencies required to execute associated
Ruby code.
関連するコードを含むディレクトリのルートに Gemfile
を配置します。例えば、Railsアプリケーションでは、Rakefile
と同じディレクトリに Gemfile
を配置します。
Gemfile
はRubyコードとして評価され、gemの要件を記述するために使用されるいくつかのメソッドが利用可能なコンテキストで評価されます。
Gemfile
の先頭に、Gemfile
にリストされているgemを含む RubyGems
のソースを1行追加します。
source "https://rubygems.org"
グローバルソースは1つしか追加できません。Bundler 1.13では、複数のグローバルソースを追加することは非推奨となりました。source
は有効なRubyGemsリポジトリである 必要があり
ます。
複数のRubyGemsソースを使用するには、source
ブロックを使用する必要があります。
ソースは、ソースの優先順位に記述されているヒューリスティックに従ってgemがチェックされます。
Bundler 1.13で非推奨になった機能の動作に関する注意:gemが複数のグローバルソースで見つかった場合、Bundlerはgemのインストール後に、どのソースが使用されたかを示す警告を表示し、gemが利用可能な他のソースをリストします。非標準のリポジトリを使用する必要があるgemに対して特定のソースを選択すると、:source
オプションまたは source
ブロックを使用することで、この警告を抑制できます。
一部のgemソースでは、ユーザー名とパスワードが必要です。bundle config(1) を使用して、必要なソースのユーザー名とパスワードを設定します。このコマンドは、Gemfileをインストールする各コンピュータで1回実行する必要がありますが、これにより認証情報がバージョン管理で平文で保存されることを防ぎます。
bundle config gems.example.com user:password
企業のGemfuryアカウントのように、一部のソースでは、認証情報をソースURLの一部としてGemfileに含める方が簡単な場合があります。
source "https://user:password@gems.example.com"
ソースURLの認証情報は、config
を使用して設定された認証情報よりも優先されます。
アプリケーションに特定のRubyバージョンまたはエンジンが必要な場合は、ruby
メソッドを使用して、次の引数で要件を指定します。特に指定がない限り、すべてのパラメータは オプション
です。
アプリケーションに必要なRubyのバージョン。アプリケーションにJRuby、TruffleRubyなどの代替Rubyエンジンが必要な場合は、エンジンと互換性のあるRubyバージョンである必要があります。
ruby "3.1.2"
Rubyバージョンをバージョンファイル(例:.ruby-version)から導出する場合は、代わりに file
オプションを使用できます。
ruby file: ".ruby-version"
バージョンファイルは、次のいずれかの形式に準拠する必要があります。
3.1.2
(.ruby-version)ruby 3.1.2
(.tool-versions, 参照: https://asdf-vm.com/manage/configuration.html#tool-versions)各アプリケーションはRubyエンジンを指定できます。エンジンが指定されている場合は、エンジンのバージョンも指定する必要があります。
エンジンとは正確には何ですか?
Rubyエンジンは、Ruby言語の実装です。
背景として:Rubyプログラミング言語の参照実装またはオリジナル実装は、Matz's Ruby Interpreter、または略してMRIと呼ばれています。これは、Rubyの作成者であるまつもとゆきひろ(通称Matz)にちなんで名付けられました。MRIはCで記述されているため、CRubyとも呼ばれます。MRIは最も広く使用されているRubyエンジンです。
Rubyの他の実装も存在します。よりよく知られている実装には、JRubyやTruffleRubyなどがあります。RubiniusはRubyで記述されたRubyの代替実装です。JRubyは、Java仮想マシン(略してJVM)上のRubyの実装です。TruffleRubyは、JVM上に構築された言語ツールキットであるGraalVM上のRubyの実装です。
各アプリケーションはRubyエンジンのバージョンを指定できます。エンジンのバージョンが指定されている場合は、エンジンも指定する必要があります。エンジンが「ruby」の場合、指定されたエンジンのバージョンは、Rubyバージョンと一致する必要があります。
ruby "2.6.8", engine: "jruby", engine_version: "9.3.8.0"
各アプリケーションはRubyのパッチレベルを指定できます。パッチレベルの指定は、Ruby 2.1.0がリリースされてから意味がなくなりました。パッチレベルは、メジャー、マイナー、およびティーンバージョン番号の組み合わせによって一意に決定されるようになったためです。
このオプションは、Ruby 2.0以前の場合にBundler 1.4.0で実装されました。
ruby "3.1.2", patchlevel: "20"
gemの要件は、gem
メソッドを使用して、次の引数で指定します。特に指定がない限り、すべてのパラメータは オプション
です。
gemの要件ごとに、単一の gem 行をリストします。
gem "nokogiri"
各gemは、1つ以上のバージョン指定子を 指定できます
。
gem "nokogiri", ">= 1.4.2"
gem "RedCloth", ">= 4.1.0", "< 4.2.0"
各gemは、Bundler.require
を介して自動requireするときに使用する必要があるファイルを指定できます
。複数のファイルを含む配列、または、required
とするファイルがgemと同じ名前の場合はtrue
、自動requireをしない場合はfalse
を渡すことができます。
gem "redis", require: ["redis/connection/hiredis", "redis"]
gem "webmock", require: false
gem "byebug", require: true
引数はデフォルトではgemの名前になります。たとえば、これらは同じです
gem "nokogiri"
gem "nokogiri", require: "nokogiri"
gem "nokogiri", require: true
各gemは、1つ以上のグループのメンバーシップを指定できます
。グループのメンバーシップを指定しないgemは、default
グループに配置されます。
gem "rspec", group: :test
gem "wirble", groups: [:development, :test]
Bundlerランタイムでは、2つの主要なメソッドであるBundler.setup
とBundler.require
で、特定のグループに影響を制限できます。
# setup adds gems to Ruby's load path
Bundler.setup # defaults to all groups
require "bundler/setup" # same as Bundler.setup
Bundler.setup(:default) # only set up the _default_ group
Bundler.setup(:test) # only set up the _test_ group (but `not` _default_)
Bundler.setup(:default, :test) # set up the _default_ and _test_ groups, but no others
# require requires all of the gems in the specified groups
Bundler.require # defaults to the _default_ group
Bundler.require(:default) # identical
Bundler.require(:default, :test) # requires the _default_ and _test_ groups
Bundler.require(:test) # requires the _test_ group
Bundler CLIでは、bundle install
でインストールしないgemのグループのリストをwithout
設定で指定できます。
無視する複数のグループを指定するには、スペースで区切られたグループのリストを指定します。
bundle config set --local without test
bundle config set --local without development test
また、パラメータなしでBundler.setup
を呼び出すか、require "bundler/setup"
を呼び出すと、--without
で除外したグループ以外のすべてのグループがセットアップされます(利用できないため)。
bundle install
では、bundlerはすべてのgemをダウンロードして評価し、必要なすべてのgemとその依存関係の単一の正規リストを作成することに注意してください。これは、異なるグループで同じgemの異なるバージョンをリストできないことを意味します。詳細については、Bundlerの理解を参照してください。
gemが特定のプラットフォームまたはプラットフォームのセットでのみ使用する必要がある場合は、それらを指定できます。プラットフォームは基本的にグループと同じですが、他のプラットフォームのgemのグループを除外するために、インストール時の--without
フラグを使用する必要がない点が異なります。
Gemfile
には、多くのプラットフォームがあります。
ruby
mri
windows
mswin
mswin64
rbx
jruby
truffleruby
プラットフォームruby
、mri
、mswin
、mswin64
、およびwindows
では、区切り文字なしでメジャーバージョン番号とマイナーバージョン番号を付加することで、バージョンを追加で指定できます。たとえば、gemがプラットフォームruby
バージョン3.1でのみ使用する必要があることを指定するには、次を使用します。
ruby_31
(上記のように)グループと同様に、1つ以上のプラットフォームを指定できます。
gem "weakling", platforms: :jruby
gem "ruby-debug", platforms: :mri_31
gem "nokogiri", platforms: [:windows_31, :jruby]
グループに関連するすべての操作(bundle install
、Bundler.setup
、Bundler.require
)は、現在のプラットフォームに一致しないグループが明示的に除外されているかのようにまったく同じように動作します。
次のプラットフォーム値は非推奨であり、windows
に置き換える必要があります。
mswin
、mswin64
、mingw32
、x64_mingw
プラットフォーム固有のバリアントよりも常にgemの純粋なrubyバリアントを選択したい場合は、force_ruby_platform
オプションを使用できます。
gem "ffi", force_ruby_platform: true
これは、(純粋なrubyバリアントが正常に機能すると仮定して)次の場合に便利です。
required_ruby_version
の上限がある)が、それでもGemfile{.lock}ファイルがそのrubyで解決されるようにしたい。':source'オプションを使用して、gemの代替RubyGemsリポジトリを選択できます。
gem "some_internal_gem", source: "https://gems.example.com"
これにより、gemがこのソースから強制的にロードされ、ファイルの最上位で宣言されたグローバルソースは無視されます。gemがこのソースに存在しない場合は、インストールされません。
Bundlerは、親に選択されたソースを最初に確認することで、このgemの子の依存関係を検索しますが、そこで見つからない場合は、グローバルソースにフォールバックします。
Bundler 1.13で非推奨になった機能の動作に関する注意:このように特定のソースリポジトリを選択すると、上記のグローバルソースで説明した曖昧なgemの警告も抑制されます。
個々のgemに:source
オプションを使用すると、明示的なソースを指定しない他のgemの可能なグローバルソースとしてもそのソースが利用可能になります。したがって、明示的なソースを持つgemを追加する場合は、Gemfile内の他のすべてのgemも明示的なソースを使用していることを確認することをお勧めします。
必要に応じて、:git
パラメータを使用して、gemが特定のgitリポジトリにあることを指定できます。リポジトリには、いくつかのプロトコルを介してアクセスできます。
HTTP(S)
SSH
git
SSHを使用する場合、bundle install
を実行するために使用するユーザーは、$HOME/.ssh
に適切なキーを持っている 必要があり
ます。
注意
: http://
および git://
URLは、可能な限り避ける必要があります。これらのプロトコルは認証されていないため、中間者攻撃者が悪意のあるコードを配信してシステムを侵害する可能性があります。HTTPSとSSHを強くお勧めします。
group
、platforms
、およびrequire
オプションは利用可能であり、通常のgemの場合とまったく同じように動作します。
gitリポジトリは、gemを含むディレクトリのルートに、.gemspec
という拡張子のファイルが少なくとも1つ 必要があり
ます。このファイルには、gem build
コマンドで予期される有効なgem仕様が 含まれている必要があり
ます。
gitリポジトリに.gemspec
がない場合、bundlerはそれを作成しようとしますが、依存関係、実行可能ファイル、またはC拡張機能のコンパイル手順は含まれません。その結果、アプリケーションに適切に統合できない可能性があります。
gitリポジトリにアタッチしたgemの.gemspec
がある場合、指定されたバージョン指定子は、.gemspec
がバージョン指定子に一致するバージョンを指定している場合にのみ、gitリポジトリが有効であることを意味します。そうでない場合、bundlerは警告を出力します。
gem "rails", "2.3.8", git: "https://github.com/rails/rails.git"
# bundle install will fail, because the .gemspec in the rails
# repository's master branch specifies version 3.0.0
gitリポジトリにアタッチしたgemの.gemspec
が ない
場合、バージョン指定子を 指定する必要があります
。Bundlerは、作成する単純な.gemspec
でこのバージョンを使用します。
Gitリポジトリは、いくつかの追加オプションをサポートしています。
branch
、tag
、およびref
できません
。デフォルトはbranch: "master"
です。例えばgem "rails", git: "https://github.com/rails/rails.git", branch: "5-0-stable"
gem "rails", git: "https://github.com/rails/rails.git", tag: "v5.0.0"
gem "rails", git: "https://github.com/rails/rails.git", ref: "4aded"
サブモジュール
submodules: true
を指定すると、bundlerがgitリポジトリに含まれるサブモジュールを展開します。gitリポジトリに複数の.gemspecs
が含まれている場合、各.gemspec
は、.gemspec
と同じファイルシステム上の場所にあるgemを表します。
|~rails [git root]
| |-rails.gemspec [rails gem located here]
|~actionpack
| |-actionpack.gemspec [actionpack gem located here]
|~activesupport
| |-activesupport.gemspec [activesupport gem located here]
|...
git リポジトリにある gem をインストールするために、Bundler は gemspec があるディレクトリに移動し、gem build name.gemspec
を実行して、結果の gem をインストールします。Rubygems に標準で付属している gem build
コマンドは、それが存在するディレクトリのコンテキストで .gemspec
を評価します。
カスタムの git ソースは、git_source
メソッドで定義できます。引数としてソースの名前を指定し、単一の引数を受け取り、それを文字列に補間して完全なリポジトリのアドレスを返すブロックを指定します。
git_source(:stash){ |repo_name| "https://stash.corp.acme.pl/#{repo_name}.git" }
gem 'rails', stash: 'forks/rails'
さらに、特定のブランチを選択したい場合は、
gem "rails", stash: "forks/rails", branch: "branch_name"
注意
: この省略形は、現在、安全でない git://
URL に展開されるため、Bundler 2.0 まで避けるべきです。これにより、中間者攻撃者がシステムを侵害する可能性があります。
使用したい git リポジトリが GitHub でホストされており、公開されている場合は、:github
の省略形を使用して、GitHub のユーザー名とリポジトリ名(末尾の ".git" を除く)をスラッシュで区切って指定できます。ユーザー名とリポジトリ名が同じ場合は、どちらか一方を省略できます。
gem "rails", github: "rails/rails"
gem "rails", github: "rails"
両方とも同等です。
gem "rails", git: "https://github.com/rails/rails.git"
github
メソッドは git_source
の特殊化であるため、:branch
という名前付き引数を受け入れます。
プルリクエストの URL を直接渡すこともできます。
gem "rails", github: "https://github.com/rails/rails/pull/43753"
これは以下と同等です。
gem "rails", github: "rails/rails", branch: "refs/pull/43753/head"
使用したい git リポジトリが GitHub Gist としてホストされており、公開されている場合は、:gist
の省略形を使用して、gist の識別子(末尾の ".git" を除く)を指定できます。
gem "the_hatch", gist: "4815162342"
これは以下と同等です。
gem "the_hatch", git: "https://gist.github.com/4815162342.git"
gist
メソッドは git_source
の特殊化であるため、:branch
という名前付き引数を受け入れます。
使用したい git リポジトリが Bitbucket でホストされており、公開されている場合は、:bitbucket
の省略形を使用して、Bitbucket のユーザー名とリポジトリ名(末尾の ".git" を除く)をスラッシュで区切って指定できます。ユーザー名とリポジトリ名が同じ場合は、どちらか一方を省略できます。
gem "rails", bitbucket: "rails/rails"
gem "rails", bitbucket: "rails"
両方とも同等です。
gem "rails", git: "https://rails@bitbucket.org/rails/rails.git"
bitbucket
メソッドは git_source
の特殊化であるため、:branch
という名前付き引数を受け入れます。
gem がファイルシステムの特定の位置にあることを指定できます。相対パスは、Gemfile
を含むディレクトリからの相対で解決されます。
:git
オプションのセマンティクスと同様に、:path
オプションでは、問題のディレクトリに gem の .gemspec
が含まれているか、Bundler が使用する必要がある明示的なバージョンを指定する必要があります。
:git
とは異なり、Bundler はパスとして指定された gem の C 拡張機能をコンパイルしません。
gem "rails", path: "vendor/rails"
ファイルシステムから複数のローカル gem を直接使用したい場合は、gem のファイルを含むパスにグローバルな path
オプションを設定できます。これにより、サブディレクトリから gemspec ファイルが自動的にロードされます。
path 'components' do
gem 'admin_ui'
gem 'public_ui'
end
:source
、:git
、:path
、:group
、および :platforms
オプションは、ブロック形式を使用することで、gem のグループに適用できます。
source "https://gems.example.com" do
gem "some_internal_gem"
gem "another_internal_gem"
end
git "https://github.com/rails/rails.git" do
gem "activesupport"
gem "actionpack"
end
platforms :ruby do
gem "ruby-debug"
gem "sqlite3"
end
group :development, optional: true do
gem "wirble"
gem "faker"
end
グループブロック形式の場合、bundle install
コマンドに渡される --with
オプションにリストされている場合を除き、グループがインストールされないように :optional
オプションを指定できます。
git
ブロック形式の場合、:ref
、:branch
、:tag
、および :submodules
オプションを git
メソッドに渡すことができ、ブロック内のすべての gem がこれらのオプションを継承します。
Gemfile に source
ブロックが存在すると、明示的なソースを指定しない他のすべての gem の可能なグローバルソースとしても、そのソースが利用可能になります。したがって、ソースブロックを定義する場合は、Gemfile 内の他のすべての gem も、ソースブロックまたは個々の gem の :source
ディレクティブのいずれかを介して、明示的なソースを使用していることを確認することをお勧めします。
install_if
メソッドを使用すると、proc または lambda に基づいて gem をインストールできます。これは、特定のソフトウェアがインストールされている場合やその他の条件が満たされている場合にのみ使用できるオプションの gem に特に役立ちます。
install_if -> { RUBY_PLATFORM =~ /darwin/ } do
gem "pasteboard"
end
.gemspec
ファイルは、Rubygems に gem に関するメタデータを提供する場所です。必須の Gemspec 属性には、gem の名前、説明、およびホームページが含まれます。ここには、gem の実行に必要な依存関係も指定します。
開発中に Bundler を使用して gem の依存関係をインストールする場合は、gemspec
メソッドを使用して、.gemspec
ファイルにリストされている依存関係を取り込みます。
gemspec
メソッドは、デフォルトグループの gem 要件としてランタイム依存関係を追加します。また、development
グループの gem 要件として開発依存関係を追加します。最後に、プロジェクト (path: '.'
) の gem 要件を追加します。Bundler.setup
と組み合わせて使用すると、プロジェクトが gem としてインストールされた場合と同様に、テストコードでプロジェクトファイルを require することができます。ロードパスを手動で操作したり、相対パスを介してプロジェクトファイルを require したりする必要はありません。
gemspec
メソッドは、オプションの :path
、:glob
、:name
、および :development_group
オプションをサポートしており、bundler が .gemspec
を検索する場所、gemspec を検索するために使用する glob (デフォルト: {,*,*/*}.gemspec
)、(複数の gemspec が存在する場合) 使用する名前付き .gemspec
、および開発依存関係が含まれるグループを制御します。
gemspec
依存関係が解決中にバージョンの競合に遭遇した場合、開発中のローカルバージョンが常に選択されます。たとえ gemspec
gem の他の要件により適合するリモートバージョンがあったとしてもです。
gem 要件を満たすために gem を探す場合、bundler は次の優先順位順で使用します。
:source
、:path
、または :git
を使用)。rubygems.org
のものよりも Rails git リポジトリからの ActiveSupport gem を優先します。