さて先日cutagemのおかげでグイグイgemが作れるようになったわけですが、せっかく作った gem が手元にだけあっても仕方ないわけです。gem 化するメリットはインストールが楽、つまり deploy が楽ということだと思っています。

まぁ公開しているものなら rubyforge や github¹ に置けばいいわけですけど、公開できないものだっていっぱいあるわけです。というかイントラでこそきちっとパッケージ管理したいと最近はよく思うわけです。

というわけで、まず基本はるびまですな。今さらながらるびまが便利すぎる。ありがとうございます。マジで。

Rubyist Magazine - シリーズ パッケージマネジメント 【第 2 回】 RubyGems (2)

ここに gem server というのが出てきますが、よく読むとこれ WEBRick を使っている。えー、WEBRick の管理なんかしなきゃいけないの？と思ったらどうも話が違うようで、ちょっと長いけど引用すると、

webrick のインスタンスを個別にに走らせる代わりに既にある自前のウェブサーバを使いたいかもしれない。問題ない。 $ ssh chad@mywebserver.com password: mywebserver$ cd /web/server/document/root mywebserver$ mkdir gemserver mywebserver$ cd gemserver mywebserver$ mkdir gems mywebserver$ scp chad@myotherhost.com:/home/chad/some_cool_lib-0.0.1.gem gems/ chad@myotherhost.com's password: some_cool_lib-0.0.1.gem 100% 11KB 11.0KB/s 00:00 全て準備できた。お預けだった gem server の話に戻ろう。 $ generate_yaml_index.rb $ ls gems yaml yaml.Z これだけ！　これでインターネットに繋がっているコンピューターならどこからでもインストールできる：

ん？

んん？

これって要するに

DOCUMENT_ROOT 以下に package 本体と index がただ置いてあるだけ

じゃないのか？ マジか。ステキすぎる。gem の server ってこんな簡単に作れるのか。てゆーか Web サーバがすでに動いている場合は実際には server 作ってないよな。index を作ってるだけだ。

すげぇ。簡単すぎる。

毎度毎度こういう言い回しに飽き飽きしてる人も多いかもしれないけど、pear の channel-server に爪のアカ飲ましてやりたい。確かに gem の場合はクライアントサイドの負荷が高いけど、pear の channel-server は MySQL を要求するとか準備がやたら面倒くさいうえにいつまでもバージョンが上がっていかず、本当にセットアップしていいんかすげー不安にさせる。結果、URI package という、package をポンと置くだけの仕組みに流れちゃったりするんだけど、そうなると install も upgrade も downgrade も直接 URI を指定しなきゃいけない、つまりクライアントサイドからは新しいバージョンがあるのかどうかも全然分からないというダメダメな状況になっちゃう。

でも gem はこの URI package と同じ仕組みで package の検索も upgrade も自動化できてる。

これでいいじゃん。

実際にはるびま本文中に出てきた generate_yaml_index.rb というものはすでになくて、代わりに

gem generate_index

というコマンドができているのでこれを使うといいです。使いやがれ。

これは便利だ！

cf.

• Twitter / wtnabe: generate_yaml_index.rb ってど …
• Twitter / wtnabe: gem generate_index だった。
• Twitter / wtnabe: gem サーバ側では HTTP を喋るサーバがいて …