今年のYAPC::Asia、いかがでしたか？

先日開催されたYAPC::Asiaはいかがでしたか？　筆者はあいにくそれほど多くのセッションに参加できたわけではないのですが、この連載ですでに取り上げたもの、まだ取り上げていないもの、そして前回原稿を書いたときにはまだ存在すらしていなかったものを含めて、有意義なセッションがたくさんありました。おかげさまで筆者も当面ネタに困ることはなさそうです。

とはいえ、あまりに旬なモジュールについては、情報の流れが速すぎて、のろまな筆者では追い切れませんので、今回と次回は、筆者が今年のYAPC::Asiaでもうひとつ発表しようかと思っていたネタをしっかりまとめておこうと思います。

ActivePerlの興隆

PerlはもともとUnixで使われていたさまざまなツールのよいところを集めて作られた言語です。だから、Perlのコマンドにはシェルやawk、Cに由来するコマンドが多数含まれていますし、その動作もおおむねUnixに準拠したものとなっていました。

もっとも、PerlはUnix環境でしか動かないというわけではありません。Unixの根底にある機能の多くはPOSIX（Portable Operating System Interface for Unix）の形で多くのOSに採用されてきましたし、そのおかげでPerlもさまざまなプラットフォームに移植されてきました。Perlに付属のperlportを見てみると、PerlはすでにUnix系のものだけで20ものプラットフォームを区別していることがわかりますし、その他のものも含めれば30を越すアーキテクチャを識別できるようになっています。

そして、その「その他」のなかには、最初期のPOSIX 1にのみ対応したWindows環境も含まれていました。

Perlが初めてWindows（や、それ以前のMS-DOS）で動くようになったのがいつだったのかは調べきれなかったのですが（少なくともjperlが1991年当時すでにMS-DOS上で動いていたことは記録に残っています⁠）⁠、ことPerl 5に関していえば、Microsoft社が1995年当時カナダのHIP Communications社にいたディック・ハルト（Dick Hardt）氏のチームに出資してPerlの移植を依頼したのがそもそもの起こりだったようです。

氏はやがて売却されたHIP社を飛び出して、ActiveWare社を設立。同社は引き続き当時のPerl 5.003をベースにWindows向けのさまざまなパッチを当てていったのですが、その対応はあくまでも自社内で行われていたため、進化を続けるPerl 5本体のコードベースとの齟齬が目立つようになっていました。

そこで、オライリー社を中心に両者を結びつける努力が始まり、ActiveWare社はActiveState社と名を変え（1997年8月⁠）⁠、同時期に独自にWindows向けPerl 5のバイナリパッケージの配布を行っていたグルサミー・サラシー（Gurusamy Sarathy）氏をも迎え入れて、Perl 5.004以降のWindows対応を本家と共同で推進していくことになりました。サラシー氏は1998年6月以降、Perl 5.004/5系列のリリースマネージャ（⁠「⁠パンプキン⁠」⁠）となり、同年7月には同社初のWindows版バイナリパッケージとなるActivePerl 5.004_69をリリース。以降、1999年末までに同社は都合22個の5.004/5向けバイナリパッケージをリリースしたほか、サラシー氏は同じく1998年7月に開発が本格化したPerl 5.6系列（正式リリースは2000年3月）のリリースマネージャも担当することになりました（～2001年⁠）⁠。

また、同社は1999年にMicrosoft社と3年契約を結んでWindows版Perlのサポートを強化するかたわら、従来のWindows版Perlでは動作しなかったforkを移植するため、MS社と共同でithreads（interpreter threads）と呼ばれるものの実装にも取り組みました。この頃の実装はまずActivePerlでテストされていたこともあって、一時期はまさにWindows用のActivePerlこそがPerlの最先端を行く実装だったものです。

また、このMicrosoft社との提携はもうひとつ、PPM（Perl Package Manager）と呼ばれる副産物も生み出しました（そのベースとなったOpen Software Description Formatの仕様は1997年にMicrosoft社らが策定したものです⁠）⁠。このPPMを使うことで、ActivePerlのユーザはCPANモジュールを（Perlバイナリと同じコンパイラでコンパイルした）バイナリの状態でインストールできるようになりました。CPANモジュールをインストールするためだけに高額なMicrosoft社のVisual C++を買う必要はなくなりましたし、わざわざMinGWやCygwinのコンパイラをインストールする必要もなくなりました[1]⁠。「⁠ActivePerlさえインストールしておけば、あとは何も入れなくて大丈夫」という手軽さが、Unix系のディストリビューションに比べて圧倒的にユーザベースの多いWindows環境でライトユーザの獲得にどれほど貢献したかは説明するまでもないでしょう。

ActiveState社の買収

こうしてPerl界にさまざまな貢献をしてきたActiveState社は、前述のサラシー氏や、LWPなどのメンテナとして有名なギスレ・オース（Gisle Aas）氏だけでなく、Inlineの作者として一躍名をはせたインギー・ドット・ネット（Ingy döt Net、当時のBrian Ingerson）氏らも合流し、当時のPerl界における一大勢力となっていました。

ところが、同社が主導したPerl 5.6系列は、Unicode対応などを謳ってはいたものの不十分なところが多いということで早々に仕切り直しの動きが始まり、2000年9月には早くも最初のPerl 5.7系列（5.8系列の開発版）が登場。2年間の開発を経て、2002年7月には正式にEncodeをフィーチャーしたPerl 5.8がリリースされます。

サラシー氏は2001年4月リリースのPerl 5.6.1を最後にリリースマネージャを降り、2002年にはMicrosoft社との契約も切れて、ActiveState社の時代はひとつの節目を迎えることになりました。PPMクライアントも2002年7月を最後にCPANには登録されなくなり、Programmer's Package Managerと名前を変えた新しいPPM 3系列のクライアントは、独自のライセンスで保護されるようになります。

それから1年。ActiveState社はアンチスパム界での実績を見込まれ、2003年9月には同業界のSophos社に吸収合併されてしまいます。Sophos社は当時100人以上もいたActiveState社の従業員には手をつけず、ActiveStateのブランド名も残し、Sophos社の一部門としてオープンソースへの貢献も続けていく旨表明したのですが[2]⁠、それまでのめざましい活躍振りに比べると、やはり同社の活動がやや鈍ったように受け止められたのは致し方のないこと。ActivePerlのリリースは公約通りSophos配下になっても年2～3回の割で続けられたのですが、それまでに比べてPPMの管理に人員や時間を割けなくなったためか、コンパイラが必要でもっともPPMパッケージ化する価値の高いXSモジュールの多くが同社のPPMリポジトリからインストールできない状態が続き、MSVCなどの開発環境を持たないライトユーザ― ─⁠─とりわけ長年Unix系の環境で経験を積み、たまたまWindows環境でもPerlの仕事をする必要に迫られたタイプのライトWindowsユーザをいらだたせていました。

Vanilla Perl

もっとも、ActiveStateのチームもただ手をこまねいていたわけではありません。Pender Financial Groupの支援を受けて2006年2月にSophos社からの独立を果たすと、ActiveState Software社としてふたたびオープンソース界へのコミットを活発化させていきましたし、その一環として、2006年8月にリリースされたActivePerl 5.8.8 Build 818では従来のコマンドラインツールにかわってTkxによるGUIを採用した新しいPPM 4を正式にリリースし、PPMリポジトリを強化していっそう初心者にやさしいPerlを目指す姿勢を打ち出しました。PPMパッケージそのものの数も激増し、現在では1万件以上のディストリビューションが公式リポジトリからダウンロードできるようになっています。

ただし、一度失った信頼を取り戻すのは容易なことではありませんでした。Windowsユーザの中でも特にUnix寄りのユーザの間では、この頃からActivePerlに見切りをつけて、よりUnix的な使い方をできるWindows向けPerlをつくろうという動きが活発化していきます。

そのきっかけをつくったアダム・ケネディ（Adam Kennedy）氏は、ActiveState社独立前夜の2006年1月に「縦1メートル分のビール」を賞品として、XSモジュールをそのままCPANからインストールできるようにフリーの開発環境を同梱した、簡単にインストールできるWindows用Perlのパッケージを募集します。その記事にはたちまち20以上のコメントがつき、以前からあったIndigoPerlや、その少し前に同じようなアプローチで業界の注目を集めていた（ものの作者の事情で頓挫していた）PXPerlなどが候補としてあげられたのですが、新しいパッケージの作成に取りかかった人も複数いました。

そのなかで最終的にもっとも早く条件を満たして賞品のビールを獲得したのはCamelPackという、ActivePerlとnmake、Dev-C++をダウンロードできるようにしたパッケージの作者でしたが、より注目を集めたのは僅差でビールを逃したカール・フランクス（Carl Franks）氏のVanilla Perlというパッケージでした[3]⁠。このVanilla Perlは、ActivePerlのライセンス問題を避けるため、一からコンパイルしたWindows用のPerlに、gccやdmakeを始めとするいくつかのUnix用ツールを同梱したもので、ファイルサイズは15メガ近くになったものの、ActivePerlに付属している追加モジュール群はインストールされないため、CPANモジュールの自動テスト環境を構築するときにはむしろ好都合という特徴を持っていました。

もっと甘いPerlを

ただし、このVanilla Perlは、自動テストのような用途には向いていますが、実際の開発をする場合、必要なモジュールをすべて一から用意しなければならないため、それほど便利とはいえませんでした。そこで生まれたのがStrawberry Perlという、Vanilla Perlをもう少し便利に拡張したパッケージです。

もともとvanillaという言葉には「基本の、基本機能しか備わっていない」という意味があり、vanilla perlという言葉そのものはこの一件よりはるか昔から「Perl本体（＋コアモジュール）のみの構成」といった意味で使われてきたのですが（少なくともperl5-portersのメーリングリストでは1996年の用例が確認できます⁠）⁠、ここではあえてそのvanillaという単語を「バニラ味の（アイスクリーム⁠）⁠」の意味でとって、「⁠イチゴ味」という別フレーバーのPerlを用意した、というのがその寓意。さらに甘口の初心者向けPerlが必要な人には「チョコレート味の」Perlを用意することになっていました。

もう少し具体的に説明すると、Strawberry Perlには、Vanilla Perlで追加されていたdmakeやgccのほかに、Bundle::CPANにまとめられているCPANからのモジュールインストールに必要な各種モジュール群や、ネットワーク管理用のBundle::LWP、XSモジュールのコンパイルに使われるExtUtils::CBuilderとExtUtils::ParseXSといったモジュールが追加されているほか、Windows上でもよく使われ、戦略的にも重要なのに外部ライブラリ不足などの理由でコンパイルに苦労することが多いものもバンドルされることになっていました[4]⁠。

このリストは年々増えてきていて、当初はWindowsの操作に必要なlibwin32や、データベース操作のためのDBI、バイナリインストール用のPAR、XML操作用のlibxml、expat、計算を高速化するgmp、そしてこれらのインストールに必要なzlibやiconvといったライブラリくらいしかバンドルされていなかったのですが（詳しくはPerl::Dist::Strawberryのソースコードをご覧ください⁠）⁠、最近ではコミュニティからの要望が多いPPMクライアントや、DBD::mysqlのようなものまでバンドルされるようになってきています。

また、その過程で、Strawberry Perlチームは積極的に各種モジュールのWindows対応を押し進める努力をしました。有名なところではTemplate-Toolkitが2007年1月から2月にかけて、一時的にアダム・ケネディ氏の管理下に入ったのがその典型例ですし、筆者も共同メンテナとして関与しているDBD::SQLiteが現在アダム・ケネディ氏の管理下に入っているのも、この一連の流れと無縁ではありません。Catalystや、最近ではMooseをウオッチしている方のなかには、::Tinyのようなモジュールばかり好んできた同氏がなぜこの界隈に？と疑問に思われていた方もいたかもしれませんが、その背後にはStrawberry Perlをもっと幅広いユーザ層に使ってもらうために苦情のもとはなるべく早く取り除いておきたい、という意図があったものと考えておけば、納得できるのではないかと思います。

Strawberry Perlに欠けているもの

ただ、Strawberry Perlは、まだまだ一般に浸透しているとは言えません。もちろんその最大の理由は、ActivePerlに比べて10年も後発だからでしょうが、メンテナ側に本職のWindows使いがほとんどいないこともあって、Windows的なフリーウェアを期待しているユーザにとっては随所に違和感が残っていることもその理由のひとつかもしれません。たとえば、インストーラの使い勝手の点ではActivePerlに及びませんし（ちなみに、最新版では残念ながらWindows 2000へのインストールができなくなっています⁠）⁠、結局PPMのバンドルを余儀なくされたように、ライトユーザ、特にWindowsネイティブのライトユーザにとって、CPAN＋gccというのは（うまく動いている分には問題ないですが）ひとたびエラーが出ると対処に困るものでしかない、というのも残念ながら真実でしょう（ふだんからCPANに親しんでいる我々にとってはなんでもないことですが、「⁠Strawberry Perlさえ入れれば、あとはなんでもCPANからインストールできる」という謳い文句だけ聞かされていた人にとっては、モジュールをインストールしようとしたらエラーが出るなんて話が違う、というのが正直な感想だろうと思います⁠）⁠。

もっとも、Strawberry Perlがそのような層をターゲットにすべきかどうかはまた別問題。コミュニティベース、しかもそのほとんどが片手間にしかWindowsを使わない開発者ばかりのStrawberry Perlが、かれこれ15年近くもWindows向けPerlやWin32専用のモジュール群のメンテナンスに関わってきたActiveState社のActivePerlと同じ土俵で相撲を取っても勝ち目はないのですから、初心者にはひとまずActivePerlを勧めて、Strawberry PerlはActivePerlに飽き足らなくなった中級者以上をターゲットにする、と棲み分けるのが無難な選択肢、と思われるのですが、Strawberry Perl界ではいま、ActivePerlに追いつけ、追い越せとばかりに、Strawberry Perlに欠けている大きなピースを埋めるための作業が続けられています。

次回はそのピースについて、簡単に現状をまとめておこうと思います。