RubyGems, Bundler, Gemfile.lock, 開発者, 運用者, それぞれの声

正確な記述ではないのですが、上記の件名について、砕けた感じで書いていきます。

1. library 開発者

1.1 古(いにしえ)の library 開発者

• 俺が作った library "AAA"、便利だから世の中に公開しよう。
• .tar.gz で圧縮して、自分の web site に置いておこうか。
• 世の中のみんなに存在を知ってもらうことは難しいなぁ。
• update したら、利用者も update してくれるだろうか。手間がかかるだろうなぁ。
• 実はこの "AAA" 1.0 は、別作者の "BBB" 2.3 を同梱しているんだけど、"BBB" 2.4 が出たらそっちと組み合わせて使ってほしいなぁ。

1.2 RubyGems 以降の library 開発者

• 俺が作った "CCC"、.gemspec さえ書いて固めれば RubyGems という仕組みでかなり自動的に install できるんだって? それは便利だ。
• しかも、この RubyGems という仕組みのために、rubygems.org という site まで用意してくれているんだって? 早速利用しよう。
• この "CCC" は別作者の "DDD" に依存しているんだけど、これも .gemspec に書いておけば gem install CCC で勝手に依存を解決してくれるんだって? 至れり尽くせりだなぁ。

1.3 少々ずぼらな library 開発者

• 俺が作った "EEE" は "FFF" に依存しているから、.gemspec に add_dependency "FFF" って書いておこう。
• いや、待てよ、俺が今の "EEE" を開発して自分の手元で test した時、"FFF" は 3.4 だったから、 add_dependency "FFF", ">= 3.4" と書いておこう。そうすれば、FFF 3.4 未満で "EEE" を動かそうとした人から「動きません」という質問をされることもなくなる。
• 何? 「"FFF" 10.0 や "FFF" 20.0 で動かなくなるかも」だって? そうかも知れないが、"FFF" の update を俺自身がずっと追いかける気はないよ。うまく動かなくなったら、Gemfile を自作して Bundler で対応してくれ。

1.4 とてもきっちりした library 開発者

• 俺が作った "GGG" は "HHH" に依存しているんだけど、実は "HHH" の作者も俺だから、依存する version 指定は add_dependency "HHH", "= 4.0.1" ときっちり固定してしまおう。どうせ "GGG" 4.0.2 と "HHH" 4.0.2 は同時に release する予定だし。

1.5 中庸な library 開発者

• 俺が作った "III" は "JJJ" に依存しているんだけど、.gemspec での version 指定をどうしようかな。
• 現行の "JJJ" 5.1.2 なら確実に動作することは分かってる。多分、"JJJ" 5.1.3, 5.1.4, 5.1.5, … というように 5.1.X なら恐らく正しく動作するだろう。
• でも、"JJJ" 5.2.0 になったら不安だなぁ。
• そうだ、 add_dependency "JJJ", "~> 5.1.2" と指定しよう。

1.6 database を使う library の開発者

• 俺が作った "KKK" は SQLite の gem か PostgreSQL の gem のどちらかが必須なんだけど、どちらか片方があればいいから、.gemspec に書くわけにはいかないなぁ。
• まあ、Gemfile の例を同梱しておいて、あとは利用者に選ばせるか。

2. application 開発者

• この "III" って便利だなぁ。この "III" を使って、application "mmm" を作ってみた。
• でも、"III" が依存している "JJJ" の 5.1.3 までは処理上の問題があって、"JJJ" 5.1.4 以降じゃないと安心して使えないから、Gemfile に gem 'JJJ', '>= 5.1.4' と書いておこう。
• え、「既存の "III" の .gemspec を書き換えたらいいんじゃないか」だって? 不可能じゃないけど、それは大仕事だ。Gemfile 1枚を記述するだけで済むなら、それでいいじゃないか。

3. application 運用者

3.1 application 配置者

• application "mmm" をわが社で導入することになった。
• なるほど、「bundle install」と実行すれば、Gemfile が許容する範囲で最新の libraries を揃えてくれるのか。
• 「bundle install」の実行が終われば、現在の環境が Gemfile.lock に記録されるんだな。
• おお、"JJJ" 7.0.0 が入ってきた? まずいな、取引先 server との protocol の都合で、6.x.x じゃないといけないから、Gemfile を書き換え、Gemfile.lock を削除して、再度 bundle install しておこう。
• "JJJ" 7.0.0 が入っていても、 bundle exec でちゃんと "JJJ" 6.x.x が呼び出されるから安心。

3.2 application 運用者

• え? 支店 X の server だけ今朝から動かない? RAID の警告を無視して使い続けていたって? 物理交換かな。昨夜の締め処理で backup が取れているのが幸いだ。
• 無事に稼働していた時の Gemfile.lock があるから、これを使おう。Gemfile.lock のおかげで、問題が発生しても切り分けが少し楽になる。
• bundle update したいだって? ダメダメ、まずは Gemfile.lock を使って旧状態に確実に復帰させることが先。どうしても bundle update したいなら、復旧後に自己責任でどうぞ。

4. 終わりに

自分で読み返してみて、あまりいい文章じゃないですが、誰かの参考になれば幸いです。

この文章を書いたきっかけは、RubyGems は依存関係を解決してくれないから Bundler が存在するという偽情報が広まってきていることに気付いたからです。RubyGems も Bundler も、どちらも依存関係を解決してくれます。ただ、その使われる階層が違うのです。

この文章に誤りを発見したら、ご指摘いただくか、または別の場所でご批判下さい。