3年前の大混乱

モダンPerl界を代表するウェブアプリケーションフレームワークといわれるCatalystが2006年半ばに5.6系統から5.7系統に移行したとき，創始者のゼバスティアン・リーデル氏を追い出す形で集団管理体制に移行した開発チームが最初にしたことは，プロジェクト開始当初から使われてきたCatalystという名のディストリビューションはそのままに，Catalyst-Runtimeという新しいディストリビューションをつくることでした。

このようなディストリビューション名の変更は，CPANクライアントを使っている分には（内部でモジュール名からディストリビューション名への変換が行われるので）問題にならないのですが，外部のパッケージ管理者たちには少なからぬ負担をかけました。なにしろ突然100を越す関連パッケージの依存が変更になるのです。基本的にはメタ情報だけ書き換えれば済む話とはいえ，従来のCatalystパッケージと新しいCatalyst-Runtimeパッケージは当然コンフリクトの対象になりますし，場合によっては，どちらが入っていてもいいという立場をとるCPANモジュール側のメタ情報と，どちらか（ふつう新しい方）しか認めないというパッケージ側のメタ情報の齟齬が生じることもありえます。まっとうな管理者であればテストもやり直すことでしょう。

ただ，この変更には，うっかりアップデートしたせいでいきなり5.6系列から5.7系列に移行させられてしまうことはない（芋蔓式に移行させられそうになってもコンフリクトが発生するので検出できる），というメリットもありました。

なにしろ集団管理体制に移行した最大の理由は，Catalystを仕事で使い始めていた人たちがリーデル氏のたび重なる仕様変更に不満を爆発させたことだったのです。たえずCPANから最新版をインストールし続けることに抵抗を感じない人はともかく，サーバを増強したら突然互換性のないバージョンがインストールされた，というのでは困ります。十分な検証が済むまで（あるいは十分な検証が済んでからも）安心して旧版のパッケージを使い続けることができるようにしておくのは，特にさまざまな環境で開発を行わなければならない人にとっては大事なことでした。

Catamooseへの移行は待ったなし

それからそろそろ3年がたち，先日，とうとう5.8系列の正式版がリリースされました。

開発版は2008年10月から公開されていましたから，なかにはすでに試された方もいるかと思いますが，このCatalyst 5.8，俗称Catamooseでは，2005年にCatalystがMaypoleというフレームワークから分離独立したときからずっと使われてきた，Catalystの根幹をなすいくつかのモジュールが，Mooseに代表されるよりモダンなモジュールで差し替えられているのが最大のポイントです。

連載第2回でも紹介したように，たしかにこれらのモジュールには問題点もありました。突っ込んだ使い方をすると不可解な挙動に悩まされたりもしましたから，その意図自体は悪くなかったのですが，なにしろ土台の部分を取り替えようというのですから，いくら後退テストを充実させたところで，古いアプリケーションのなかには壊れてしまうものも出てきます。

今回の移行はまだ始まったばかりですから戦略の正否を評価できる段階にはありませんが，今回は，前回とは違って，ほかのパッケージをアップデートしただけのつもりでいたら，芋蔓式に新しいCatalystがインストールされて，古いアプリケーションに影響が出る，ということも十分起こりえます。

今回は筆者が実際に遭遇した問題を中心に，Catalyst 5.8に移行したときに起こりうる問題とその解決策を紹介していきましょう。

継承ツリーの操作にはご用心

伝統的に，Catalystアプリケーションのひな形は（コメントを除くと）このような形になっていました。

package MyApp;

use strict;
use warnings;
use Catalyst::Runtime '5.70';
use Catalyst qw/-Debug ConfigLoader Static::Simple/;

our $VERSION = '0.01';

__PACKAGE__->config( name => 'MyApp' );;
__PACKAGE__->setup;

1;

このMyAppは，Catalyst.pmを継承したコンテキストオブジェクト（$c）であり，Catalyst::Controllerを継承したコントローラコンポーネントでもあるのですが，このようにuseしただけでCatalystがMyAppの継承ツリーに入ってしまうのはどうなのか，という議論があったため，2008年4月にリリースされたCatalyst::Devel 1.05以降，parentという新しいプラグマを利用して，Catalystを明示的に継承ツリーに追加するようになりました。1.05の書き方はすぐにあらためられてしまったので，1.06のひな形を紹介すると，このような感じになります。プラグインのロードがsetupのところに移動しているのがポイントです。

package MyApp;

use strict;
use warnings;
use Catalyst::Runtime '5.70';
use parent qw/Catalyst/;

our $VERSION = '0.01';

__PACKAGE__->config( name => 'MyApp' );;
__PACKAGE__->setup(qw/-Debug ConfigLoader Static::Simple/);

1;

Catalyst 5.8でも，このようなひな形通りの書き方になっていれば，新旧ともに問題ありません。

ところが，ここで両者を組み合わせてこのようなMyApp.pmを書くと，Catalyst 5.8ではエラーになります。

package MyApp;

use strict;
use warnings;
use Catalyst::Runtime '5.70';
use Catalyst qw/-Debug ConfigLoader Static::Simple/;
use parent 'Catalyst';  # または push @ISA, 'Catalyst';

our $VERSION = '0.01';

__PACKAGE__->config( name => 'MyApp' );;
__PACKAGE__->setup;

1;

おもしろいことに，この場合はuse parentをuse baseに変えるとエラーが消えるのですが，MooseベースになったCatalyst 5.8は，メソッド解決にC3を利用しているせいもあって，コンポーネントをuseしたあとに継承ツリーをいじられることを極度に嫌います。

この場合は古いやり方にしたがってuse parentの行を削除するか，現行のCatalyst::Devel 1.12がしているように，use parentの行をuse Catalystの上にもっていく，あるいは，旧版との互換性を考えなくてもよいなら，次に紹介するMoose的なやり方に変えてもよいでしょう。baseプラグマやparentプラグマを利用するときは，なるべくMooseの影響が出ないように，先に持っていくのが無難です。