Docs header transparent bg

gemfile

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メソッドを使用して、次の引数で要件を指定します。特に指定がない限り、すべてのパラメータは オプション です。

バージョン(必須)

アプリケーションに必要な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の他の実装も存在します。よりよく知られている実装には、JRubyTruffleRubyなどがあります。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"

Gems

gemの要件は、gemメソッドを使用して、次の引数で指定します。特に指定がない限り、すべてのパラメータは オプション です。

名前(必須)

gemの要件ごとに、単一の gem 行をリストします。

gem "nokogiri"

バージョン

gemは、1つ以上のバージョン指定子を 指定できます

gem "nokogiri", ">= 1.4.2"
gem "RedCloth", ">= 4.1.0", "< 4.2.0"

Require As

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.setupBundler.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
C Ruby (MRI)、Rubinius、またはTruffleRubyですが、Windowsではありません
mri
C Ruby (MRI)のみですが、Windowsではありません
windows
RubyInstallerの32ビットおよび64ビットバージョンを含む、Windows C Ruby (MRI)
mswin
RubyInstallerの32ビットバージョンを含む、Windows C Ruby (MRI)
mswin64
RubyInstallerの64ビットバージョンを含む、Windows C Ruby (MRI)
rbx
Rubinius
jruby
JRuby
truffleruby
TruffleRuby

プラットフォームrubymrimswinmswin64、および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 installBundler.setupBundler.require)は、現在のプラットフォームに一致しないグループが明示的に除外されているかのようにまったく同じように動作します。

次のプラットフォーム値は非推奨であり、windowsに置き換える必要があります。

  • mswinmswin64mingw32x64_mingw

Force_ruby_platform

プラットフォーム固有のバリアントよりも常にgemの純粋なrubyバリアントを選択したい場合は、force_ruby_platformオプションを使用できます。

gem "ffi", force_ruby_platform: true

これは、(純粋なrubyバリアントが正常に機能すると仮定して)次の場合に便利です。

  • プラットフォーム固有のバリアントに問題がある。
  • プラットフォーム固有のバリアントが新しい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

必要に応じて、:gitパラメータを使用して、gemが特定のgitリポジトリにあることを指定できます。リポジトリには、いくつかのプロトコルを介してアクセスできます。

HTTP(S)
gem "rails", git: "https://github.com/rails/rails.git"
SSH
gem "rails", git: "git@github.com:rails/rails.git"
git
gem "rails", git: "git://github.com/rails/rails.git"

SSHを使用する場合、bundle installを実行するために使用するユーザーは、$HOME/.sshに適切なキーを持っている 必要があり ます。

注意: http:// および git:// URLは、可能な限り避ける必要があります。これらのプロトコルは認証されていないため、中間者攻撃者が悪意のあるコードを配信してシステムを侵害する可能性があります。HTTPSとSSHを強くお勧めします。

groupplatforms、および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リポジトリは、いくつかの追加オプションをサポートしています。

branchtag、およびref
これらのオプションは、最大で1つしか指定 できません。デフォルトは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"

サブモジュール
参考までに、gitサブモジュールを使用すると、リポジトリのサブフォルダ内に別のgitリポジトリを配置できます。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 ソースは、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"

Github

注意: この省略形は、現在、安全でない 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"

Gist

使用したい 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 という名前付き引数を受け入れます。

Bitbucket

使用したい 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 という名前付き引数を受け入れます。

Path

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 のブロック形式

: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

install_if メソッドを使用すると、proc または lambda に基づいて gem をインストールできます。これは、特定のソフトウェアがインストールされている場合やその他の条件が満たされている場合にのみ使用できるオプションの gem に特に役立ちます。

install_if -> { RUBY_PLATFORM =~ /darwin/ } do
  gem "pasteboard"
end

Gemspec

.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 は次の優先順位順で使用します。

  1. gem に明示的にアタッチされたソース (:source:path、または :git を使用)。
  2. 暗黙的な gem (明示的な gem の依存関係) の場合、親で宣言されたソース、git、またはパスのリポジトリ。これにより、bundler は rubygems.org のものよりも Rails git リポジトリからの ActiveSupport gem を優先します。
  3. 上記のいずれの条件も満たされない場合、グローバルソースが使用されます。複数のグローバルソースが指定されている場合、最後から最初の順に優先されますが、これは Bundler 1.13 以降は非推奨であるため、Bundler は警告を出力し、将来はエラーで中止されます。
GitHub でこのドキュメントを編集するエラーを見つけたり、何かが不足していることに気付いた場合は。