Gemfile.lockファイルについて

181

bundle installコマンドを実行すると、作業ディレクトリに「Gemfile.lock」が作成されます。そのファイル内のディレクティブはどういう意味ですか？

たとえば、次のファイルを見てみましょう。

PATH
  remote: .
  specs:
    gem_one (0.0.1)

GEM
  remote: http://example.org/
  specs:
    gem_two (0.0.2)
    gem_three (0.0.3)
      gem_four (0.0.4)

PLATFORMS
  platform

DEPENDENCIES
  gem_two
  gem_one!

「PATH」、「GEM」、「PLATFORMS」、「DEPENDENCIES」は何を説明していますか？それらのすべてが必要ですか？

' remote 'および ' specs 'サブディレクティブを何に含める必要がありますか？

' DEPENDENCIES 'グループの宝石名の後の感嘆符はどういう意味ですか？

ruby bundler gemfile.lock

— Shamaoke
ソース

71

バンドルウェブサイトで詳細を確認できます（便宜上、以下に強調を追加しています）。

しばらくアプリケーションを開発した後、GemfileおよびGemfile.lockスナップショットとともにアプリケーションをチェックインします。これで、リポジトリには、アプリケーションが正常に機能したことを確認するために最後に使用したすべての宝石の正確なバージョンの記録があります...

これは重要です。Gemfile.lockは、アプリケーションが独自のコードと、すべてが正常に機能したことを確認した最後に実行したサードパーティコードの両方の単一パッケージにします。Gemfileで依存するサードパーティコードの正確なバージョンを指定しても、通常、gemは依存関係のバージョンの範囲を宣言するため、同じ保証はありません。

— フィリペミゲルフォンセカ
ソース

65

これは彼の質問のいずれにも答えませんでした、彼はGemfile.lockのフォーマットについて尋ねていますが、これはそれが何をするかを説明するだけです。

— ジョシュアチーク

38

感嘆符に関しては、それがを介してフェッチされた宝石にあることがわかりました:git。たとえば、

gem "foo", :git => "git@github.com:company/foo.git"

— Agenteo
ソース

うわー、それを理解する素晴らしい仕事、私もこれを疑問に思いました。ありがとう。

— JP Silvashy 2013

5

pathオプションを介してローカルのGemをロードするときにも発生します。私はそれがコンパイルされていないgemのロードと関係があると思いますか？

— zykadelic 2014年

はい、これは理由です。しかし、これが宝石に感嘆符が付けられる唯一の理由ではありません。現在、ソースブロック内で感嘆符が付いていると宣言されているgemが表示されています。

— Sean Moubry 2016年

35

ここ数か月間、GemfilesとGemfile.locksをいじくり回しながら、自動化された依存関係更新ツール¹を構築してきました。以下は決定的なものではありませんが、Gemfile.lock形式を理解するための良い出発点です。また、Bundlerのロックファイルパーサーのソースコードを確認することもできます。

Bundler 1.xによって生成されたロックファイルには、次の見出しがあります。

GEM（オプションだが非常に一般的）

これらは、Rubygemsサーバーから供給される依存関係です。これは、Rubygems.orgのメインのRubygemsインデックスである場合と、Gemfuryなどから入手可能なカスタムインデックスである場合があります。このセクションには、次の内容が表示されます。

remote: Rubygemsインデックスの場所を指定する1つ以上の行
specs: 依存関係のリスト、バージョン番号、およびサブ依存関係の制約

GIT（オプション）

これらは、特定のgitリモートから供給される依存関係です。gitリモートごとにこれらのセクションの異なる1つが表示され、各セクション内に次のように表示されます。

remote:gitリモート。例えば、git@github.com:rails/rails
revision: Gemfile.lockがロックされているコミット参照
tag: （オプション）Gemfileで指定されたタグ
specs: このリモートで見つかったgit依存関係、バージョン番号、およびサブ依存関係の制約

PATH（オプション）

これらはpath、Gemfileで提供される特定のをソースとする依存関係です。パスの依存関係ごとにこれらのセクションの異なる1つが表示され、各セクション内に次のように表示されます。

remote:パス。例えば、plugins/vendored-dependency
specs: このリモートで見つかったgit依存関係、バージョン番号、およびサブ依存関係の制約

プラットフォーム

Gemfile.lockが生成されたRubyプラットフォーム。Gemfileのいずれかの依存関係がプラットフォームを指定している場合、それらは、ロックファイルがそのプラットフォームで（たとえば、インストールによって）生成されたときにのみGemfile.lockに含まれます。

依存関係

で指定されている依存関係のリストと、Gemfileそこで指定されているバージョン制約。

Rubygemsのメインインデックス以外のソースで指定された依存関係（git依存関係、パスベース、依存関係など）は、!ソース^2に「固定」されていることを意味します（ただし、Gemfileで確認する必要がある場合もあります）。

ルビーバージョン（オプション）

このGemfile.lockが作成されたときにGemfileで指定されたRubyバージョン。Rubyバージョンが.ruby_versionファイルで指定されている場合、このセクションは存在しません（BundlerはGemfile / Gemfile.lockをインストーラーのRubyバージョンに依存しないと見なすため）。

バンドル（Bundler> = v1.10.x）

Gemfile.lockの作成に使用されたBundlerのバージョン。ファイルを作成したバージョンよりも古い場合、Bundlerのバージョンを更新するようにインストーラーに通知するために使用されます。

PLUGIN SOURCE（オプションで非常にまれ）

理論的には、GemfileはBundlerプラグインとgems ³を指定でき、それらはここにリストされます。実際には、2017年7月の時点で、使用可能なプラグインについては知りません。Bundlerのこの部分はまだ開発中です！

— グレイスタイル
ソース

2

最良の答えのようです

— daslicious '15

9

Bundlerは、必要なGemとバージョンを正確に追跡してインストールすることにより、Rubyプロジェクトに一貫した環境を提供するGemマネージャーです。

GemfileとGemfile.lockは、Bundler gemによって提供される主要な製品です（Bundler自体はgemです）。

Gemfileには、指定したバージョンで手動で言及するgemへのプロジェクトの依存関係が含まれていますが、それらのgemは、バンドルによって自動的に解決される他のgemに依存しています。

Gemfile.lockには、関連する依存関係とともに、Gemfile内のすべてのgemの完全なスナップショットが含まれています。

bundle installを初めて呼び出すと、このGemfile.lockが作成され、その後のすべてのbundle install呼び出しでこのファイルが使用されます。これにより、すべての依存関係がインストールされ、依存関係のインストールがスキップされます。

コードを別のマシンと共有する場合も同じです

Gemfileと一緒にGemfile.lockを共有します。他のマシンでbundle installを実行すると、Gemfile.lockを参照し、依存関係の解決手順をスキップします。代わりに、複数のマシン間で一貫性を維持する元のマシン

複数のマシンで一貫性を維持する必要があるのはなぜですか？

異なるマシンで異なるバージョンを実行すると、コードが破損する可能性があります
アプリがバージョン1.5.3を使用していて、14か月前
に問題
なく動作し、Gemfile.lockなしで別のマシンにインストールしようとすると、バージョン1.5.8になります。多分それはいくつかのgemの最新バージョンで壊れていて、あなたのアプリケーションは
失敗するでしょう。一貫性を維持することが最も重要です（推奨される
方法）。

bundle updateを使用して、Gemfile.lockのgemを更新することもできます。

これは保守的な更新の概念に基づいています

— ケシャフ
ソース

8

PATHは第1世代の依存関係をgemspecから直接リストするのに対し、GEMは第2世代の依存関係（つまり、依存関係が依存するもの）とGemfileからの依存関係をリストするように見えます。PATH :: remoteは.、PATH :: specに属しているものを見つけるために現在のディレクトリのローカルgemspecに依存しているためです。一方、GEM :: remoteはrubygems.org、GEM ::に属しているものを見つけるために移動する必要があるためです。スペック。

RailsプラグインではPATHセクションが表示されますが、Railsアプリでは表示されません。アプリにはgemspecファイルがないので、PATHに入れるものは何もありません。

依存関係については、gembundler.comは次のように述べています。

Runtime dependencies in your gemspec are treated like base dependencies, 
and development dependencies are added by default to the group, :development

によって生成されたGemfile rails plugin new my_pluginは同様のことを言っています：

# Bundler will treat runtime dependencies like base dependencies, and
# development dependencies will be added by default to the :development group.

これが意味することは、

s.add_development_dependency "july" # (1)

そして

s.add_dependency "july" # (2)

（1）は、開発環境のGemfile.lock（およびアプリケーション）に「july」のみを含めるということです。したがって、を実行するとbundle install、PATHだけでなくDEPENDENCIESの下にも "開発中"と表示されます。本番環境ではまったく存在しません。ただし、（2）を使用すると、依存関係ではなくPATHにのみ「july」が表示されますbundle installが、本番環境（依存関係として自分を含む他のgemなど）からは表示されますが、開発のみ。

これらは私の見解であり、なぜこれがどのようになっているのかを完全に説明することはできませんが、私はさらなるコメントを歓迎します。

— アイザック・ベテッシュ
ソース

3

Gemfile.lockフォーマットについて話している明確な文書はないようです。たぶんそれGemfile.lockは内部でバンドルによって使用されているためです。

ただし、Gemfile.lockはのスナップショットでGemfileあるため、そのすべての情報はGemfile（またはで指定されていない場合はデフォルト値から）取得する必要がありますGemfile。

以下のためにGEM、それはあなたが直接または間接的に導入し、すべての依存関係を示していますGemfile。remoteunder GEMは、gemの取得場所を指示します。これは、のソースで指定されていGemfileます。

宝石からフェッチされていない場合はremote、PATHそれを見つけるために場所を伝えます。PATHの情報は、依存関係を宣言したときのパスから取得さGemfileれます。

そしてここPLATFORMからです。

の場合DEPENDENCIES、これはバンドルによって解決された依存関係のスナップショットです。

— ホン
ソース

0

「DEPENDECIES」グループの宝石名の後の感嘆符はどういう意味ですか？

「https://rubygems.org」以外のソースを使用してgemがインストールされた場合、感嘆符が表示されます。

— SWiggels
ソース