github.comoslo-consensusSource編集(github)変更履歴(github)誤訳の報告この翻訳についてこの文書は、https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/oslo-consensus.mdを翻訳したものです。Kennedyが命名したものです。Consensusコンテキストと環境変数テストの「コンテキスト」という概念に関しては、この段階で抜け漏れなく議論するのはまだ時期尚早であるということで合意しました。この段階でも2つの特殊なコンテキストの仕様を定めるのは理にかなっていること、コンテキストの公式な命名規則はないにしても、テストシステムの方でこれらのコンテキストが適用されているかをどう判定すべきかは環境変数を使えば決められる、ということで合意しました。テストのコンテキストを扱う際にはほかの手軽なメソッドが使われるかもしれませんが、環境変数が有効になっている場合はそれがコンテキストをあらわす正統なフラグとして扱われる予定です。AUTOMATED_TESTING$ENV{AUTOMATED_TESTING}フラグの現在の使い方は、人間の操作に対するリソースが割り当てられない自動テストのコンテキストを示すことで合意しました。$ENV{PERL_AUTOMATED_TESTING}についての議論も多少ありましたが、特定の言語によらないフラグを好む意見の方が圧倒的でした。これは特に参加者がTAPに偏り、特定の言語によらないムードが強かったためです。コンテキストフラグを特定の言語によらないようにしておくことで、ほかの、異なる言語で(あるいは、こちらの方が重要ですが、複数の言語が混ざった環境で)TAPベースのテストを行うような環境でも再利用しやすくなるだろうとも感じました。これらを別々のフラグとして定義しておくことで、複数のコンテキストを組み合わせたくなった場合の柔軟性もあがるはずです(たとえば、同じAUTOMATED_TESTINGの環境でも、リリーステストも実行したい環境もあるでしょうし、そうでない環境もあるでしょう)。実装もより単純になるはずです。Criticなど)の使い方は十分に成熟し、広まっているので、このコンテキスト用の環境変数を定義するのも理にかなっている、とも感じました。このコンテキストについては、現在はさまざまな開発者やシステムが、$ENV{AUTHOR_TESTING}、$ENV{PERL_AUTHOR_TESTING}、$ENV{RELEASE_TESTING}、Perlディストリビューションにおけるxt/ディレクトリの使用など、多種多様なフラグを使っています。このコンテキストは、「作者用のテスト」ではなく「リリーステスト」として定義するのが最善であるということで合意しました。dist」の時点で行うのがもっとも便利であり、開発中に継続的に行うものではないためです。AUTHOR_TESTINGの使い方が一部の作者を混乱させているという報告もありました。「author」という単語が使われていることから、一部の作者はこのフラグを恒久的に有効にしていたのですが、これはこのコンテキストの使い方として意図したものではありませんでした。この件があったため、$ENV{RELEASE_TESTING}をリリース/作者用のテストを実行すべきコンテキストを示す正統なフラグとして標準化することで合意しました。xt/ディレクトリ過去数ヶ月の間に、ディストリビューションのリリーステストのスクリプトを置く場所として、また場合によってはリリーステストのスクリプトであることを表現する正統な方法として、「xt/」という別のディレクトリを使う例がいくつか見られるようになりました。xt/ディレクトリというコンセプトは理にかなっていることがわかりました。}という大きなコードの塊を含める必要がなくなるためです)。(現在のt/ディレクトリの使い方はさておき)ディレクトリ名を正統な識別子として使うのは適切ではないとも感じました。管理が難しくなりそうですし、コンテキストを組み合わせるときにも問題になりそうだからです。M:I等)にも実装すべきであるということで合意しました。これによって、単純きわまりない場合の利便性を考慮しつつも、必要な場合は柔軟に対応できるようになるはずです。META.ymlのrelease_dependsキーMETA.ymlには現在以下のキーがあります。(Makefile.PL/Build.PL等を実行時の依存モジュール)リリーステストが必要とする依存モジュールを指定するためにrelease_requires:キーを追加することについての議論もいくらかありました。原理的には理にかなっているものの、これは過剰な仕様であり、リリーステストを実行する人はテストが失敗したのに気がついたら自ら手作業で依存をインストールするくらいのことはできてしかるべきであるという感じになりました。AUTOMATED_TESTINGとRELEASE_TESTINGがあわさったコンテキストであっても、リリーステストは利用するモジュールがインストールされていなかったらskip_allするくらいには賢くあるべきです。同様に、META.ymlにさらに何らかの依存コンテキストを追加指定するのは時期尚早として避けるよう勧告しました。その日の後刻、FreeBSDのPerlメンテナとの会話で、test_requires:をbuild_requires:から分けるといくらか有益かもしれないとの指摘がありました。(と、もしかするとGentoo)は依然としてソースからビルドする場合の大量の依存モジュールに苦しむことになるためです。これらの問題はさらに調査が必要なものです。そのため、今回はMETA.ymlに依存モジュールを指定するセクションを追加しないよう勧告することに決めました。$version」という形で指定し続けるべきであると決定しました。0.42これは、専用のperl_version:キーのようなものを持つより現在の慣習を残す方がよいという判断です。その理由は主に、perl:キーをほかの依存ブロックに拡張すれば現在の状態から追加の値をとれるようになるためです。5.006」を入れておき、その結果異常終了したものの後始末をするよりすぐれた代替手段として便利に活用できます。configure_requires:は信頼できる設定なので、CPANクライアントはその値を確かめればディストリビューションのMakefile.PLやBuild.PLが実行可能かどうか確認できるためです(実際にMakefile.PLを実行する必要はありません)。そのため、理想的ではないけれども最適の解決策として、perl:の慣習をすべてのrequiresブロックに拡張することである、ということで合意しました。これはその後、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の議論をしていたのでした)。上記は相応に議論を尽くされた決議であるとも感じているので、ツールチェーンモジュールの作者は上記の実装をすぐに始める予定です。Association。