この翻訳について

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

オスロ・コンセンサス

オスロ・コンセンサスというのは2008年のOslo QA hackathonに参加したツールチェーンおよび品質保証のメンテナ間で行われた合意にAdam Kennedyが命名したものです。

原文はuse.perl.orgにて公開されました: The Oslo Consensus

コンテキストと環境変数

テストの「コンテキスト」という概念に関しては、この段階で抜け漏れなく議論するのはまだ時期尚早であるということで合意しました。

ただし、この段階でも2つの特殊なコンテキストの仕様を定めるのは理にかなっていること、コンテキストの公式な命名規則はないにしても、テストシステムの方でこれらのコンテキストが適用されているかをどう判定すべきかは環境変数を使えば決められる、ということで合意しました。

テストのコンテキストを扱う際にはほかの手軽なメソッドが使われるかもしれませんが、環境変数が有効になっている場合はそれがコンテキストをあらわす正統なフラグとして扱われる予定です。

AUTOMATED_TESTING

$ENV{AUTOMATED_TESTING}フラグの現在の使い方は、人間の操作に対するリソースが割り当てられない自動テストのコンテキストを示すことで合意しました。

$ENV{PERL_AUTOMATED_TESTING}についての議論も多少ありましたが、特定の言語によらないフラグを好む意見の方が圧倒的でした。これは特に参加者がTAPに偏り、特定の言語によらないムードが強かったためです。

コンテキストフラグを特定の言語によらないようにしておくことで、ほかの、異なる言語で(あるいは、こちらの方が重要ですが、複数の言語が混ざった環境で)TAPベースのテストを行うような環境でも再利用しやすくなるだろうとも感じました。

また、これらを別々のフラグとして定義しておくことで、複数のコンテキストを組み合わせたくなった場合の柔軟性もあがるはずです(たとえば、同じAUTOMATED_TESTINGの環境でも、リリーステストも実行したい環境もあるでしょうし、そうでない環境もあるでしょう)。また、実装もより単純になるはずです。

`RELEASE_TESTING`

作者/リリース専用のテストスクリプト(PODテスト、Perl Criticなど)の使い方は十分に成熟し、広まっているので、このコンテキスト用の環境変数を定義するのも理にかなっている、とも感じました。

このコンテキストについては、現在はさまざまな開発者やシステムが、$ENV{AUTHOR_TESTING}、$ENV{PERL_AUTHOR_TESTING}、$ENV{RELEASE_TESTING}、Perlディストリビューションにおけるxt/ディレクトリの使用など、多種多様なフラグを使っています。

このコンテキストは、「作者用のテスト」ではなく「リリーステスト」として定義するのが最善であるということで合意しました。圧倒的大多数の場合、このテストは「make dist」の時点で行うのがもっとも便利であり、開発中に継続的に行うものではないためです。

AUTHOR_TESTINGの使い方が一部の作者を混乱させているという報告もありました。「author」という単語が使われていることから、一部の作者はこのフラグを恒久的に有効にしていたのですが、これはこのコンテキストの使い方として意図したものではありませんでした。

この件があったため、$ENV{RELEASE_TESTING}をリリース/作者用のテストを実行すべきコンテキストを示す正統なフラグとして標準化することで合意しました。

xt/ディレクトリ

過去数ヶ月の間に、ディストリビューションのリリーステストのスクリプトを置く場所として、また場合によってはリリーステストのスクリプトであることを表現する正統な方法として、「xt/」という別のディレクトリを使う例がいくつか見られるようになりました。

xt/ディレクトリというコンセプトは理にかなっていることがわかりました。これは主に、レガシーなツールチェーンとも完全な後方互換性があり、テストスクリプトの中で必要になるコードも非常にシンプルなものになるためです(if ( $ENV{RELEASE_TESTING} ) { ... } elsif ( $ENV{AUTOMATED_TESTING} ) { .. }という大きなコードの塊を含める必要がなくなるためです)。

ただし、(現在のt/ディレクトリの使い方はさておき)ディレクトリ名を正統な識別子として使うのは適切ではないとも感じました。管理が難しくなりそうですし、コンテキストを組み合わせるときにも問題になりそうだからです。

その結果、リリーステストのコンテキストとしては$ENV{RELEASE_TESTING}を信頼できる識別子として残しつつも、「xt/」ディレクトリをリリーステストの置き場所を示す手軽な方法として使う場合のサポートをツールチェーンモジュール(EU:MM, M:B, M:I等)にも実装すべきであるということで合意しました。

これによって、単純きわまりない場合の利便性を考慮しつつも、必要な場合は柔軟に対応できるようになるはずです。

META.ymlのrelease_dependsキー

META.ymlには現在以下のキーがあります。requires: (実行時の依存モジュール), build_requires: (ビルド/テスト/インストール時の依存モジュール)、configure_requires: (Makefile.PL/Build.PL等を実行時の依存モジュール)

リリーステストが必要とする依存モジュールを指定するためにrelease_requires:キーを追加することについての議論もいくらかありました。原理的には理にかなっているものの、これは過剰な仕様であり、リリーステストを実行する人はテストが失敗したのに気がついたら自ら手作業で依存をインストールするくらいのことはできてしかるべきであるという感じになりました。

AUTOMATED_TESTINGとRELEASE_TESTINGがあわさったコンテキストであっても、リリーステストは利用するモジュールがインストールされていなかったらskip_allするくらいには賢くあるべきです。

同様に、META.ymlにさらに何らかの依存コンテキストを追加指定するのは時期尚早として避けるよう勧告しました。

なお、その日の後刻、FreeBSDのPerlメンテナとの会話で、test_requires:をbuild_requires:から分けるといくらか有益かもしれないとの指摘がありました。というのも、FreeBSDのソースパッケージはユーザがビルドしますが、テストは実行されないため、結果的に、下流のパッケージがバイナリパッケージのbuild_requires:を消し始めても、FreeBSD (と、もしかするとGentoo)は依然としてソースからビルドする場合の大量の依存モジュールに苦しむことになるためです。

ただし、これらの問題はさらに調査が必要なものです。そのため、今回はMETA.ymlに依存モジュールを指定するセクションを追加しないよう勧告することに決めました。

requires: perlキー

非常に活発な議論の末、以下のように、依存するPerlの最低バージョンはrequires:の中に「perl: $version」という形で指定し続けるべきであると決定しました。

---
requires:
    perl: 5.006
    Test::More: 0.42

これは、専用のperl_version:キーのようなものを持つより現在の慣習を残す方がよいという判断です。

その理由は主に、perl:キーをほかの依存ブロックに拡張すれば現在の状態から追加の値をとれるようになるためです。

個人的にはビルド/テストコンテキストで別のバージョンのPerlへの依存を宣言したい理由はあまりよくわかりませんが(もっとも、何らかの理由を思いつく人がいるであろうことはわかっています)、configure_requires:のperl:キーは、Makefile.PLを実行して、その中に「use 5.006」を入れておき、その結果異常終了したものの後始末をするよりすぐれた代替手段として便利に活用できます。

configure_requires:は信頼できる設定なので、CPANクライアントはその値を確かめればディストリビューションのMakefile.PLやBuild.PLが実行可能かどうか確認できるためです(実際にMakefile.PLを実行する必要はありません)。

そのため、理想的ではないけれども最適の解決策として、perl:の慣習をすべてのrequiresブロックに拡張することである、ということで合意しました。

META_LOCAL.yml

[編者注: これはその後、META_LOCALからMYMETAへとリネームされました]

CPANツールチェーンの懸案事項のひとつに、Makefile.PL/Build.PLスクリプトとCPANクライアントのやりとりに関する問題があります。現在は2つのまったく異なる方法でやりとりしていますが、いずれも理想的なものではありません(実際、Makefile.PLの方法はきわめてハックの要素が強いといえるでしょう)。

公式の場で本当に議論されたわけではありませんが(何人かのツールチェーン開発者の間では話し合われました)、オプションのひとつとして、特定のホストに固有の信頼できるメタデータ(META.ymlファイル)をやりとりするのにも、信頼できないメタデータをやりとりするのにすでに使っているのと同じ方法を使う、という案があります。

この問題をオスロのQAグループに持ち込んだとき、この案には圧倒的な支持がありました。特にDebianの人々の反応は歓喜に近いものでした。この案が意味するのは、ようやく彼らはビルド時の依存と実行時の依存を区別できるようになり、その結果Debianのバイナリパッケージの依存からすべてのテストモジュールを外せる、ということだからです。

既存のMETA.ymlを編集するか、新しいファイルを書くか(そしてそのファイルをどう呼ぶか)について多少議論した結果、ツールチェーンモジュールは、既存の方法に桑手、META_LOCAL.ymlというファイルを生成すべきであると決まりました。

このファイルはMETA.ymlと同じメタデータを含むべきですが、さまざまな依存情報(や、あらゆる関連情報)はそのホストに固有の値に書き換えるべきです。

まとめ

上記の問題が解決したことで、適切に解決可能な2つのトピックはそろそろ議論し尽くしつつあるように感じましたし、さらに重要な点として、グループのメンバーもそろそろ疲れ切っているように感じました(その多くは2日間びっしりTAPの議論をしていたのでした)。

もっとも、上記は相応に議論を尽くされた決議であるとも感じているので、ツールチェーンモジュールの作者は上記の実装をすぐに始める予定です。