その他の翻訳 > github.com

lancaster-consensus

この翻訳について

この文書は、https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/lancaster-consensus.mdを翻訳したものです。

ランカスター・コンセンサス

2008年にオスロで開催された最初のPerl QA Hackathonでは、Perlの品質管理やツールチェーンに関係するモジュールの作者、メンテナ、有識者が多数集まり、よくある標準や慣行のいくつかについて合意を行いました。このとき発表された合意は「オスロ・コンセンサス」という名で知られるようになりました。

5年後、2013年のPerl QA Hackathonでも、同様の専門家集団が集まり、新たに統一見解が必要になった問題について議論しました。

以下の決定事項は今後の方針を示すものではありますが、例によって実装にかかる時間は、実際の作業にあたるボランティアの事情や、実際の作業にあたるボランティアが現れるかどうかによります。

ツールチェーンとテスト

サポートするPerlの下限

今後、Perlのツールチェーンは2003年9月にリリースされたPerl 5.8.1を対象とすることになります。これによって、ツールチェーンモジュールは、PerlIOや、Perl 5.8で改善されたUnicodeサポートを安心して利用できるようになります。

なお、5.8の初期のいくつかのリリースではUnicode関係のバグフィックスが多数行われたため、ツールチェーンのメンテナはあとからこの下限を5.8.4に引き上げる権利を留保するものとします(これはSolaris 10に同梱されているバージョンです)。

Pure Perlでビルドするよう指定する

ディストリビューションによっては「XS」版と「Pure Perl」版を用意して、Makefile.PLやBuild.PLを実行する段階でいずれかを選択できるようにしているものがあります。現時点では、これらのディストリビューションはそれぞれ独自のやり方でユーザに選択させているため、CPANクライアントやその他のビルドツールの側では、この選択を自動化させたいユーザを助けたくても助けられない状況になっていました。

今後、Makefile.PLとBuild.PLの「仕様」には、以下のように「Pure Perl」版のみビルドさせるコマンドラインオプションが含まれるようになります。

PUREPERL_ONLY=1 (Makefile.PLの場合)
--pureperl-only (Build.PLの場合)

これらのオプションは、ほかのコマンドラインオプション同様に、PERL_MM_OPTないしPERL_MB_OPTという環境変数に設定してもかまいません。

ディストリビューションの作者は、これらのオプションが存在している場合、インストールするモジュールが(直接、あるいはInlineモジュールを通じて)XSをロードしたりプラットフォーム固有のコードを動的に生成したりしなくてもすむように保証しなければなりません。インストールされたファイルは、アーキテクチャが異なってもPerlのバージョンが同じならば、(たとえばアプリケーションを「fatpack」するなどして)別のマシンにコピーしても正しく動作できるようになっていなければなりません。この条件を満たせない場合、Makefile.PLやBuild.PLはエラーを吐いて終了しなければなりません。

テストがどのような状況で実行されているか(コンテキスト)を指定するための環境変数

オスロ・コンセンサスではテストのコンテキストをあらわすものとしてAUTOMATED_TESTINGとRELEASE_TESTINGという2つの環境変数を定義しましたが、そのうちAUTOMATED_TESTINGについては、きわめて紛らわしいものになってしまいました。場合によって、「ユーザとのやりとりをさせない」という意味で使われたり、「時間のかかるテストを実行する」という意味で使われてきたためです。

ランカスターではDist::ZillaのようなツールがAUTHOR_TESTINGとRELEASE_TESTINGを現在どう区別しているかについても(短時間ですが)議論しました。

ディストリビューションの作者は今後以下のようなセマンティクスに従うようにしてください。

AUTOMATED_TESTING: この環境変数が真の場合、テストを実行しているのは何らかの自動テストの仕組みであり、モジュールをインストールしている最中ではない、ということを意味します。CPANスモーカーはこの環境変数を真にしなければなりません。また、CPANクライアントはこの環境変数を設定してはなりません。
NONINTERACTIVE_TESTING: この環境変数が真の場合、テストの最中にユーザとやりとりしようとするべきではありません。テストの出力は表示されないこともありますし、プロンプトからの答えは返ってきません。
EXTENDED_TESTING: この環境変数が真の場合、テストを実行しているユーザないしプロセスは、終わるまでに余計な時間がかかったり余分なリソースを必要とするかもしれないオプションのテストも実行するつもりがあるということを意味します。ただし、このようなテストには開発用のテストや品質管理用のテストを含めてはなりません。実行時の機能をテストするもののみ含めるべきです。
RELEASE_TESTING: この環境変数が真の場合、テストはリリース時の品質管理プロセスの一部として実行されているということを意味します。CPANクライアントはこの環境変数を設定してはなりません。
AUTHOR_TESTING: この環境変数が真の場合、テストは作者の個人的な開発プロセスの一部として実行されているということを意味します。このようなテストは、リリースの前に実行されるかどうかはわかりません(実行されるかもしれませんし、そうでないかもしれません)。CPANクライアントはこの環境変数を設定してはなりません。ディストリビューションパッケージャ(ppm, deb, rpm等)もこの環境変数を設定するべきではありません。

CPANにはこれらの環境変数の設定を正しく、簡単に行えるようにするライブラリがすでに2つあります。

CPANスモーカーや統合テスターは自動の非インタラクティブなテストを行っていることを明示しなければなりません。また、リソースにもよりますが時間のかかるテストも行うよう求めるかもしれません。

CPANクライアントは、必要や設定に応じて自由に非インタラクティブなテストや時間のかかるテストを行うよう求めることができます。

CPANスモーカーやクライアントは、「設定してはならない」環境変数にあらかじめ明示的に値が設定されていた場合、その値を消してはなりません。

Build.PLの仕様の修正

David GoldenとLeon TimmermansはBuild.PLの仕様策定に取り込んできました。この仕様は、Build.PLを使ったPerlのビルドツールがどのように振る舞わなければならないかを示すもので、必然的にModule::Buildに準拠したものになりますが、かならずしもModule::Buildの挙動に完全に従わなければならないわけでもありません。

ランカスターでは、.modulebuildrcの用法と意味は仕様から外すべきであるということで合意しました。

インストール済みディストリビューションのデータベース

QA Hackathonのプロジェクトのひとつに、packlistの代わりとなる何かを作成するというものがありました。インストール済みディストリビューションのデータベースがあれば、インストール済みディストリビューションの簡単な一覧や、アンインストールツール、インストール済みモジュールの依存グラフのトラッキングなどが簡単にできるようになるはずです。

ランカスターでは、モジュールは多くの異なった場所にインストールされうることから、そのようなデータベースは「@INCごと」に用意する必要があること、また、@INC自身と同じやり方でスタックに積み上げていく必要があることで合意しました。つまり、@INCにパスを追加したら、データベースがインストール済みとみなすモジュールは変化しうるということです。

また、このようなデータベースシステムがコア以外の依存モジュールを要求することはあってはならないことですが、推奨されるCPANモジュールがインストールされている場合に拡張機能を提供することはありえます。

その他の実装の詳細についてはシステムを設計する人にお任せします。

インストール後のテスト

Hackathon参加者の中にはモジュールをインストールした後でもそのモジュールのテストを実行できるようにするシステムに関心を持っていた方が数名いました。これは、たとえば依存モジュールをアップグレードしたことでモジュールが壊れていないか確認したり、全体の整合性をテストするためのものです。

ランカスターでは、そのようなテストを行う場合、テスト中にディストリビューション内のすべてのファイルを利用できるようにしなければならない、つまり、テストはディストリビューションのtarballがあるディレクトリから実行しなければならないことで合意しました。また、そのようなテストはmake test-installedやBuild test-installedという、新しいmakeないしBuildターゲットを使って実行しなければなりません。これらのターゲットはmake testやBuild testに相当するものになるべきですが、@INCにはblibを足さないようにするべきです。proveアプリケーションを使ってはなりません。

また、そのようなテストの際には、@INCによるモジュールの見え方(隠れ方)も尊重する必要があることでも合意しました。PERL5LIBを設定すると「インストールされている」ディストリビューションが変わる可能性がありますし、それによってどのテストを実行すべきかも変わりえるので、インストール済みディストリビューションのデータベースとの連携が勧められました。

その他の実装の詳細については、ディストリビューションのディレクトリの内容を最初のインストール時に保存するか、あるいはCPAN/BackPANからあらためて取ってくるかを含めて、システムを設計する人にお任せします。

METAファイルの仕様

「provides」フィールド

CPAN::Meta::Specの「provides」フィールドは「file」キーを必須としていますが、動的に生成されるパッケージの場合、その意味が明確になっていませんでした。ランカスターでは、「file」キーはそのパッケージが由来するディストリビューションのディレクトリ内にある実際のファイルを参照しなければならない(そのファイルが.pmファイルであるか.PLファイルであるか、あるいはほかの動的に生成しているファイルであるかは問わない)、ということで合意しました。

「conflicts」の改善

ランカスターでは、依存モジュール情報(prerequisite)のデータに含まれる「conflicts」キーの既知の問題についてもいくつか簡単に議論しました。

どうやらほとんどの開発者が求めているのは、ある特定のモジュールをインストールするとほかの特定のバージョンのモジュールを壊すことが知られている(たとえば、Fooを2.0にアップグレードすると3.14より古いすべてのBarが壊れる)、ということを示す方法です。

この問題の改善に興味がある方には、x_breaksないし類似のカスタムキーを使い、CPANクライアントにそれをサポートしてもらうためのパッチを取り込んでもらってプロトタイプを作ることをお勧めします。実戦で十分なテストが済んだら、将来的には仕様バージョン3の候補となるかもしれません。

PAUSEとCPAN

PAUSE上にあるディストリビューションレベルのデータについての長期的な目標

議論の俎上にのぼったPAUSEの問題点のいくつかから、PAUSEはパッケージ(名前空間)レベルのインデックスやパーミッションのデータのほかに、「ディストリビューション」レベルのデータも維持していく必要があるということが明確になりました。そうすることで、たとえば、いまはディストリビューションのパーミッションを譲渡しようとするとすべてのパッケージのパーミッションを譲渡しなければなりませんが、そのかわりにディストリビューションを単位としたパーミッションの譲渡ができるようになります。

ランカスターでは、これは長期的な目標としては適切であるものの、短期的には目の前の問題を解決するため、ほかの提案を実装していこうということで合意しました。

大文字小文字を問わないパッケージのパーミッション

直接議論されたわけではありませんが、注記しておくべきこととして、PAUSEのパッケージパーミッションについては近々大文字小文字を問わないようになる予定です。ただし、大文字小文字を区別しないファイルシステムにインストールされたときでもインデックスされるモジュールは確実にユニークになるよう、大文字か小文字かは保存される予定です。

ディストリビューション名の規則

CPANエコシステムに属するウェブサイトやツールの多くは、「ディストリビューション名」をユニークな識別子として利用していますが、これまでのところ、それがユニークであることを強制するものは何もありません。ユニークでないことを許容することは、どんなによく言っても混乱のもとですし、最悪の場合セキュリティリスクになります。

今後、PAUSEにアップロードされるディストリビューションは、ディストリビューション内にあるインデックスされるパッケージ名と「対応する」名前を持たなければならなくなります。また、アップロードする人はそのパッケージのパーミッションを持っていなければなりません。さもないと、ディストリビューション全体がインデックスされなくなります。

たとえば、DAGOLDENがFoo-Bar-1.23.tar.gzをアップロードする場合、ディストリビューション名は「Foo-Bar」で、そのディストリビューションにはインデックス可能な「Foo::Bar」というパッケージがなければならなくなります。

CPANにはこの規則に従わないディストリビューションが1000件ほどありますが、これらについては新しい規則の例外とします。ただし、これらのディストリビューションについても、ディストリビューション名を変えるか、新たに.pmファイルを追加する、あるいは内部的に適切な名前のパッケージを導入して、標準にあわせることが勧められます。

たとえば、LWPはlibwww-perl-6.05.tar.gzとしてリリースされていますが、もしその.pmファイルのひとつにpackage libwww::perl;という一文が含まれていたら、そのパッケージがインデックスされて標準に従うことになります。

技術的には、「provides」フィールドを使えば正しいパッケージ名をMETA.jsonファイルの中でのみ宣言することも可能です。その場合、「file」の値は「META.json」にして、そのパッケージを宣言しているファイルが「META.json」であることを明示しなければなりません。

放棄されたモジュールや協力を求められているモジュールに印をつける

現時点では、CPANモジュールの作者が亡くなった場合、その人のモジュールのパーミッションは「ADOPTME」という架空の作者に譲渡されます。そのモジュールをメンテしたいボランティアがいれば、名乗り出て引き継ぎの要求をすることもできます。

ランカスターでは、モジュールが放棄されている、あるいは作者が責任を共有してくれる人を探していることを示す場合も、短期的には同様のメカニズムを使うべきであるということで合意しました。ただし、作者が亡くなっている場合と異なり、これらの場合は目印としてコメンテの権限を使い、原作者が必要に応じてその目印を削除できるようにする予定です。

(長期的には、PAUSEにディストリビューションレベルのデータモデルによって、このニーズにより直接的に対処できるようになるものと期待しています。)

CPAN検索エンジンなどのコミュニティサイトは、これらのパーミッションの目印やそれに関連づけられた意味を利用してディストリビューションの状態を伝えてもかまいません。

ADOPTME (プライマリの場合): これは一般的に作者が亡くなっていることを示します。ボランティアは[email protected]経由で引き継ぎを要求できます。
ADOPTME (コメンテの場合): これは応答がないことを確認済みの作者を示します。コミュニティは、パッケージにこの目印をつける際には引き継ぎの場合と同様の(つまり、作者に複数回連絡をとってみたうえで、[email protected]経由で要求するという)ルールに従うよう提案するかもしれません。ボランティアは[email protected]経由でADOPTMEモジュールの引き継ぎを要求できます。追加の待ち時間は必要ありません。
HANDOFF (コメンテナの場合): これは作者が永久にプライマリメンテナの役割を誰かほかの人に渡してしまいたいと願っていることを示します。
NEEDHELP (コメンテナの場合): これは作者がモジュールのメンテを手伝ってくれる人は探しているものの、プライマリメンテナであることは続けようと計画していることを示します。

ADOPTMEからの「引き継ぎ」を例外として(これは[email protected]を通さなければなりません)、CPANモジュールの作者はこれらのコメンテ権限を通常のPAUSEインタフェースを利用して管理しなければなりません。

また、CPANモジュールの作者は、PAUSEの管理者に要求があればすぐにパーミッションを譲渡してもよいということを示すために、プライマリないしコメンテの権限を自分でADOPTMEに譲渡してもかまいません。

PAUSE IDの自動登録

歴史的にPAUSE IDは手作業で承認されてきたため、登録までにはしばしばかなりの遅れが出ることがありました。ランカスターでは、ロボットやスパムに対する適切な保護策があればという前提のもとで、PAUSEは自動承認システムに移行すべきであると合意しました。これでPAUSEもほかのプログラミング言語のリポジトリやオープンソースコミュニティのサイトと肩を並べられるようになるはずです。

また、ランカスターでは、未使用で、活動の形跡もないPAUSE IDは一定期間後に削除して再利用できるようにすべきであるということで合意しました。具体的なことをいうと、過去に何かをアップロードしたことのあるPAUSE IDは削除してはなりません(BackPANにはそのPAUSE IDにひも付くファイルが存在しているからです)。また、PAUSEにログイン(あるいは、rt.cpan.orgなどのプロキシを経由)すれば十分に活動の形跡があるとみなされます。活動の形跡がないIDも、PAUSEにログインするよう警告するメッセージもなしに削除されることはありません。

CPANディレクトリの自動クリーンアップ

CPAN上のファイルのうち、およそ半分ほどが5年より前のものですが、CPANモジュールの作者の多くは古いディストリビューションをまったく消してくれません。CPANの大きさを抑えるため、ランカスターでは、何らかの条件のもと、古いディストリビューションは自動的に削除するよう手配していく(そして、結果的にBackPANにしか存在しないようにする)ことで合意しました。

削除の対象として選ばれるディストリビューションは、最低でも3つの安定版が存在していなければなりません。その3つの安定版のうちもっとも古いものよりもさらに古いディストリビューションのうち、5年より前のもので、02packagesファイルにインデックスされていないものはすべて削除するよう手配されることになります。

perlのtarballはもちろんすべて削除の対象外となります。

削除が手配されたことは通常通り作者に通知されます。また、削除の手配をキャンセルする猶予期間も通常通り与えられます。

クリーンアップは何らかの方法でPAUSE IDが対象になった順に行い、CPANモジュールの作者に頻繁に削除通知が届くのを避けるように実装される予定です。

モジュールの登録

ランカスターでは、PAUSEのモジュール登録はその有用性をもうほとんど失っているということで合意しました。登録されているのはほんの一部のCPANモジュールであるため、メタデータ(たとえば「DSLIP」)の総合提供源となることもできず、カバーされている情報も多くはMETAファイルを通じてもっと広範に入手できるためです。

ランカスターでは、いまでも新しいCPANモジュールの作者が最初のモジュールを登録しようとしたときにしばしばフィードバックをもらえるという利点が残っていることは認めましたが、PrePANなどほかの場所の方が新しい作者にはよい経験を提供できるようになるだろうという感じもしました。特にPrePANは1～2人のPAUSEの管理者にとどまらないコミュニティの参加があり、(メーリングリストのアーカイブを検索しなくても)学べる例を豊富に提供してくれています。

そのため、ランカスターでは既存のPAUSEのドキュメントを変更して、助言がほしい場合はPrePANに行くよう新しい作者に(また、経験を積んだ作者にも)案内するようにしていくことで合意しました。

近々PAUSEはモジュール登録データベースをCPANミラーに公開するのをやめる予定です(インデックスファイルがあることを期待するCPANクライアントを壊さないよう、インデックスファイルは残しておきますが、中身は空にする予定です)。評価期間が終わったら、モジュール登録はおそらく閉じて、この機能もPAUSEから取り除くことになる予定です。

ランカスター・コンセンサスの議論に参加した方々

議論は3日間にわたり、多少の出入りはあったものの、毎日20人ほどが議論に参加しました。以下の参加者各位に感謝します。

Andreas Konig, Barbie, Breno Oliveira, Chris Williams, Christian Walde, David Golden, Daniel Perrett, Gordon Banner, H. Merijn Brand, James Mastros, Jens Rehsack, Jess Robinson, Joakim Tormoen, Kenichi Ishigaki, Leon Timmermans, Liz Mattijsen, Matthew Horsfall, Michael Schwern, Olivier Mengue, Paul Johnson, Peter Rabbitson, Philippe Bruhat, Piers Cawley, Ricardo Signes, Salve J. Nilsen and Wendy van Dijk

(参加者で一覧から漏れている方がいらしたらごめんなさい。dagolden at cpan dot orgにメールするかpull requestを送っていただければ追加します)