Ruby on Railsをやり始めたときだと、Gemfileって何？そんでbundle installするとつくられるGemfile.lockって何？みたいな感じですよね。
今日は、GemfileとGemfile.lockの簡単なお話です。
gemっていうのは、Javaでいうところのライブラリみたいなものです。結構頻繁に使われるあるまとまった処理があって、それを毎回開発するたびに書いているのは大変なのでgemという形にしてみんなが使えるようにして配布しているわけですね。
開発者は、この機能を作りたい！そのためには、このgemが必要だ！って思った時は、Rails.rootにあるGemfileに追加します。
だけど、gemの中にはさらに別のgemを使っているgemもあったりして、さらにそのgemも別のgemを使っていて…とかが往々にしてあります。
さらに、Aというgemを使うためにはZというgemのバージョン1.2.1が必要だけど、Bというgemを使うためには、Zというgemを使うんだけど、1.3.0のバージョンが必要で…みたいな話もあります。
そこで、Railsだと、bundle installするときにそのあたりの依存性をよしなに解決してくれるわけですね。そして、その解決した依存性をGemfile.lockというファイルに記録します。
Gemfile.lockをリポジトリに入れて管理しておけば、そのリポジトリを別の環境に持っていったときも依存性は解決されているので、Gemfile.lockに従ってgemをインストールすればいいことになって、便利です。
ただ、たまに、Gemfile.lockそのままじゃだめなときがあります。私の過去の経験の話を少しします。
当時、開発は、AWS上のEC2で行ったり、Macのローカルの環境で行ったりしていました。gemの中には、なぜかEC2では難なくインストールできたのに、Macではうまくインストールされないというものがありました。
仕方がないので、私は、そのgemをGemfile.lockから消し、もう一度bundle installを行うとよしなに依存性が解決され、別のバージョンのgemがインストールされました。それで、無事めでたくbundle installを行うことが出来ました。
もちろん、本番環境とローカルでは、gemのバージョンが異なってくるわけですが、デプロイ時は本番環境に近い環境でbundle installするので、当時は問題は発生していませんでした。
私も含め初学者はこのあたりブラックボックスのまま突き進むことがあると思いますが、ちょっと振り返ってみました。
詳しい話は、（ベタですが）次の記事にお任せします。
www.rubylife.jp
