というわけでここ数日 Plagger Blog みたいになってますがご容赦を。Plagger ネタを追いかけたい方は del.icio.us の plagger タグ でほぼ網羅できているとおもうので、ここをチェック。

で、Plagger とプラグインシステムです。「なんで Plagger はプラグインをコアの中にいれて配布しているの？ 別個に配布したほうが便利なのに」 という疑問を当然お持ちの方もいるかとおもいました。

ここはだいぶ議論になったところで（といっても IRC チャネル #plagger-ja で小１時間しゃべっただけですが）、実際に Trac でチケット #44: Reorganize plugin directories in SVN も切られてます。

ただ、現状は svn の plagger/lib/Plagger/Plugin 以下に svn commit してもらう方法をとっていて、これが最適だとおもっています。その理由を説明する前に、Perl でつくられたソフトウェアがどのようにプラグインをロードしているかの例を調べたので、ちょっと紹介しましょう。

Ingy dot Net による "DIY Wiki building kit" ともいうべき Wiki システム。ほとんどすべてがプラグインで構成されています。

* プラグインの作成方法: Perl モジュール

* プラグインの配布方法: CPAN / Ingy の svn レポジトリ

* プラグインのロード: Kwiki::Installer に対応したプラグインの場合は、 kwiki -add Kwiki::Foo を実行。それ以外の場合、各 Kwiki インストレーションの plugins ファイルにモジュール名を書き込む。設定は config.yaml に共通

長所: CPAN で配布が可能

短所: Kwiki コアの API が変わると、古いプラグインが動かなくなる

Kwiki の開発はかなり安定してきているので、CPAN を利用した配布方法も現実的です。ただ、ちょっと前までは、Ingy が Kwiki のバージョンをあげると、動かなくなるプラグイン続出、という状況でした。"Ingy, you broke my Kwiki plugin" というセリフを何度聞いたことか。

Ask Bjorn Hansen による SMTP サーバ構築キット。これも、すべてがプラグイン。

* プラグインの作成方法: ファイルを plugins/ 以下におく

* プラグインの配布方法: svn で qpsmtpd のコアにインクルード

* プラグインのロード方法: config/plugins にプラグインファイル名を１行１モジュールで記述。設定はスペース区切りの引数で追加

長所: svn で管理しているため、本体との API の整合性がとりやすい

短所: CPAN からインストールできない

qpsmtpd は CPAN にはリリースされておらず、svn での開発がメインとなっています。debian のパッケージや ports などが用意されているので、CPAN からインストールできないデメリットはあまり感じません。

* プラグインの作成方法: ファイルに記述。モジュール化したりテンプレートといっしょにディレクトリにバンドルしたりすることが可能

* プラグインの配布方法: Plugin Direcotry または各自のサイト

* プラグインのロード: plugins/ ディレクトリにファイルまたはディレクトリごと配置。ロード後、MT 管理画面から enable/disable することも可能

* プラグインの設定: 各プラグインの管理画面から設定

長所: ただファイルを配置するだけから、 高度なプラグイン開発、設定まで幅広く対応可能

短所: Plugin Directory などのサイトを検索する必要。また開発者にとってはディレクトリサイトの管理などの手間

MT はそれ自体完成したソフトであり、またオープンソースのライセンスではないので、CPAN からという手段は考える必要がありませんね。

というわけで Plagger です。現状はこうです。

プラグインの作成方法: Perl モジュール

プラグインの配布方法: svn の plagger ディストロ内

プラグインのロード: config.yaml に module: ブロックを記述

というわけで現状は、作成とロードを Kwiki に学び、配布を qpsmtpd に学んでいます。ただし Perl モジュールの形式なので、あとあと CPAN にアップすることも可能になっていますし、プラグインのロードはファイル単位でおこなうこともできます（#8 参照。config.yaml で指定した plugin_path: にファイルをおけば、lib/Plagger/Plugin/Foo/Bar.pm なんてところに野良プラグインをおかなくても大丈夫です）。

リリースごとに API を変更している現状や、コミッターがどんどん増えている状況を考えれば、現状これが最適にワークしていると思えます。もしそうでなければ、ユーザは、必要になるプラグインを全部別個にインストールしなくてはならず、プラグインのデベロッパーは、Plagger コアやその他のプラグインの依存関係をケアしながら Makefile.PL を記述して１個ずつ CPAN に毎回アップして、その CPAN のミラーに半日かかるのを待って ... なんてバカげたことをしなくてはなりません。時間とリソースの無駄。

Plugin を同梱することでインストールがめんどうになっているのでは？ という疑問についてはこれは誤解です。外部プラグインが必要とするモジュールについては 0.5.4 から Makefile.PL にすべて記述していますし、オプショナルと思えるプラグインについては、デフォルトで [n] となってスキップします。

UNIX システム (Linux や Mac OSX) でもっとも簡単な方法は、CPAN シェルで cpan> test Plagger として依存モジュールをインストールし、あとは svn up で Plagger の最新を「インストールせずに」使うということでしょう。Win32 ではたしかにメンドウですが CPAN シェルと ppm で依存モジュールをいれてしまえば、あとは pure perl なので大変なところはないはずです。

もっとくわしくプラグインの実装方法について知りたい！ という方は、qpsmtpd の作者である Ask の Build Easily Extensible Perl Programs (PDF) が参考になるかも。

Posted by miyagawa at March 1, 2006 06:28 AM | Permalink