2010-07-19

Bundler 0.9.26 を触ってみた

あぁ、快適だ。例え Windows でも画面もキーボードも小さくても、Emacs バインドで書ける喜び1

Bundler との出会い

先日、pear packageでアプリの依存ライブラリを管理するようにし始めたわけですが、もとはと言えばこれは jruby-appengine を調べていたときに知った

Bundlerがめっちゃ便利そう

というところからスタートしています。

もともと依存パッケージは管理する必要があると感じていたわけですが、とりあえずリストアップして README 辺りに書いてありゃいいのかなぁとか軟弱なことを思ったりしていました2。しかし jruby-appengine を調べたときには

  • 必要な gem も含めて全部勝手に deploy されてるらしい
  • bundle っていう gem がなにやら超絶便利らしい

ということを知り、どうにか勉強しなきゃと思っているうちにまた半年が経っていました3

インストールと基本的な使い方

Bundler: The best way to manage Ruby applications

gem install bundler
bundle help

ですね。

Bundler でできること

  • 依存している gem package を Gemfile というファイルで管理できる4
  • Gemfile をもとに bundler が download、install を行うことができる
  • download した *.gem パッケージを cache することができる ( bundle package )
    • install の際には gem server だけでなく、この cache も利用することができる
  • local にも remote にも Bundler を入れておくことで、deploy 時に自動的に依存 gem も更新することができる
  • Bundler を利用したライブラリの読み込みのサポート ( Bundler.setup )

Bundler: The best way to manage Ruby applications

この辺に書いてあるのですが、group に分けておいた gem package 群を必要に応じて require することができるようです。例えば test 用のライブラリは開発環境でだけ読み込む、といったことを個別に記述することなく Bundler.setup だけで実現できる。らしいです。自分はそこまでたどり着いてはいないのですが。

deploy ツールと連携して remote の gem を管理する

実は当初、bundle package でできる cache/*.gem さえあればいいのかと勘違いしていました。でもそんなことないですよね。そりゃそうだ。実際には

bundler を使って gem をインストールする際に cache/*.gem があれば gem サーバを見にいかなくて済むよ

という話でしかありません。

また、remote での gem のインストールも Bundler によって自動化されるのではなく、

remote にインストールされている Bundler を呼んでくれる deploy ツールによって実現されています。

そりゃそうか。

そりゃそうかの連続。そりゃそうかの連続なんだけど、この仕組みを思いついた人はやっぱり頭いいなぁ。

逆に言うと deploy ツールがない場合は開発環境の準備が多少楽になるよ、程度の意味しかありません。たぶん。まぁそれも重要なんですけど。依存パッケージをいちいち調べたり、動かし始めてからアレがないコレがないという状態になるのはとてもイライラしますから。

Bundler 1.0 へ

ROADMAP というファイルを読むと、今後は 0.10, 1.0 と進んでいくようで、0.9 からは API は変更しない模様。逆に言うと 0.9 の間は変更し放題かな? 実際、0.9.4 と 0.9.5 の間に断絶があるらしいです。

他の環境への応用を考える

Ruby で deploy ツールと言えばもちろん Capistrano 系になるわけですが、これらは基本的に shell アクセスを要求します。repository からコードを取得してサーバを再起動するまで全自動で行います。スバラシイ。

では shell アクセスが不可能な場合はどうしたらよいのでしょう。例えばレンタルサーバでの CGI や PHP 開発では?

PHP の場合は

  • include_path さえ通っていれば、ライブラリの読み込みはできる
  • include_path は .htaccess からスタートするアプリケーション動作の流れの中で定義できる
  • Pear package は pure PHP で書かれていることが保証されており、単に extract しただけで使える
  • Pear package は gem のように複数バージョンを管理することはできない

という感じなので、

  1. 指定の package を取得してきて
  2. package を extract して
  3. アプリケーションのコードと一緒に put

できるだけでいいはずです。例えばこの最低限度の機能が実現できれば deploy ツールがなくてもアプリケーションとその依存パッケージを同時に deploy できます。

pecl とか使う場合は build もサーバの再起動も必要になるので話は変わってきますが、星の数ほどあるレンタルスペースベースの小規模 PHP 案件はこれで十分ですし、小規模こそ、この辺りの作業に掛ける手間は減らすべきです5

やっぱり PHP にこそ欲しいですねぇ、これ。

参考

  1. 下書きを netbook + Evernote で書きました。 

  2. 一方で、システムを丸ごと再現する際には個々のアプリの情報なんか知ったこっちゃなくて、結局何が要るの?ということで現在入っている pear の list をもとに手作業で入れ直しとかするんですよね。これも非常にダサいです。 

  3. このときの様子は delicious 上にしか残っていません。 

  4. 名前は変更できる 

  5. そうでないと数をこなせない 

About

例によって個人のなんちゃらです