Getting more information that the CPAN Testers page reports ( 取得 詳細情報の CPAN Testers ページリポートの )

How can I display a log of what happened? ( どのように私は表示しますか ログを 何が起こったかの ? )

Warning! Add File::Slurp::Tiny as one of your pre-reqs.

警告 ! 追加します File::Slurp::Tiny を あなたの pre-reqs ( 前提 ) のひとつとして.

Create a showlog.t:

作成します showlog.t を:

#!perl



use strict;



use Test::More tests => 1;

use File::Slurp::Tiny qw(read_file);



my $log = read_file("config.log");

ok( $log, "show config.log" ) and diag ($log);

config.log is auto-generated, so don't worry about that. But, you may need to consider the order in which the test scripts are run.

config.log は自動生成されます, なので 心配しないでください それについて. しかし, あなたは必要かもしれません 順序を考慮することが そのテストスクリプトの実行で.

Making distributions CPAN Testers friendly ( 作成する ディストリビューションを CPAN Testers フレンドリーな )

"How to prepare my distribution for parallel testing?" ( どのように準備しますか 私のディストリビューションを 並列テストのために ? )

Your distribution might not be prepared for parallel testing for several reasons:

あなたのディストリビューションは準備ができないかもしれません 並列テストのための いくつかの理由で:

1. The tests depend on a strict sequence.
2. They created some kind of required data that might conflict with other tests (you might want to check Test-Temp-Dir to help with that).
3. They share necessary data between them.

1. テストは依存します 厳密なシーケンスに.
2. それらが作成する ある種の必要なデータは 競合するかもしれない 他のテストと ( あなたはチェックしたいかもしれません Test-Temp-Dir (# 現在は代わりに Test::TempDir::Tiny ) を それを助けるために ).
3. それらは共有する 必要なデータを それらの間で.

Best way to check this is use the HARNESS_OPTIONS environment variable (see [[cpan::Test-Harness POD) and run the distribution tests.

ベストな方法は これをチェックする 利用することです HARNESS_OPTIONS 環境変数を ( 参照します [[cpan::Test-Harness POD を ) それと 実行します ディストリビューションテストを.

If you can't change your tests in case of failure (or are just lazy to do it) you can make yourself a favor and avoid a lot of errors reports by configuring TAP-Harness rules parameter of the new method with a YAML file. Check the POD of it, or, (if you're really lazy) just add the create a file named "testrules.yml" inside the distribution "t" directory with the following content

もしあなたが変更できないなら あなたのテストを 失敗した場合に ( またはただ面倒 それをするのが ) あなたはできます あなた好みに それと 回避できます 多くのエラーリポートを 設定することによって TAP-Harness のルールパラメータを 新しいメソッドの YAML ファイルで. チェックします その POD を, または, ( もしあなたが本当に怠惰なら ) ただ追加します ファイルを作成して "testrules.yml" という名前の ディストリビューションの "t" ディレクトリに 次の内容で

---

seq: t/*.t

This will force all tests to be executed sequentially and avoid error reports.

これは強制します すべてのテストを実行することを 順番に それと 回避します エラーリポートを.

You can also figure out that errors reported while running your distributions tests were cause by parallel testing by checking the environment information in the report itself:

あなたはまた見つけ出すことができます リポートされたエラーを 実行中に あなたのディストリビューションのテストを 並列テストによって引き起こされたと 環境情報をチェックすることで リポート自体の:

------------------------------

ENVIRONMENT AND OTHER CONTEXT

------------------------------

Environment variables:

  HARNESS_OPTIONS = j4

The present of such the "j" parameter for HARNESS_OPTIONS will confirm that for you.

存在は "j" パラメータのような HARNESS_OPTIONS の 確認します あなたのために.

"How can I indicate that my distribution only works on certain versions of Perl?" ( どのように私は示しますか 私のディストリビューションが特定のバージョンでのみ動作することを Perl の ? )

A minimum Perl version should be specified with a "use VERSION" statement at the top of the Makefile.PL and/or Build.PL. Be sure to use the older style of version numbers. E.g.

最小の Perl バージョンは 指定する必要があります "use VERSION" 構文で Makefile.PL and/or Build.PL のトップの. 必ず使用します 古いスタイルを バージョン番号の. E.g.

# In Makefiel.PL or Build.PL

use 5.006: # NOT 5.6.0

You can also specify a prerequisite of 'perl' in a Build.PL, but older versions of Module::Build don't check this early enough when running Build.PL so you can't rely on it to avoid fatal (and confusing) errors running Build.PL. You should still do this to ensure that your perl prerequisite is included in META.yml.

あなたはまた指定できます prerequisite ( 前提条件 ) を 'perl' の Build.PL で, しかし古いバージョンは Module::Build の これをチェックできません じゅうぶん早くは 実行時に Build.PL の. あなたはこれをまだする必要があります 確実にするために あなたの perl prerequisite が含まれるように META.yml に.

# In Build.PL as an argument to Module::Build->new()

requires => {

  'perl' => 5.008001,

}

The MakeMaker equivalent with ExtUtils::MakeMaker versions >= 6.47 is:

MakeMaker は 同等の ExtUtils::MakeMaker バージョン >= 6.46 での:

# In Makefile.PL as an argument to WriteMakefile()

MIN_PERL_VERSION => '5.008001';

Older MakeMaker versions did not have an equivalent -- adding perl to PREREQ_PM is not supported. MakeMaker 6.48 comes bundled with Perl 5.8.9, more recent versions are available on CPAN.

古い MakeMaker のバージョンは持っていません 同等のものを -- perl の追加は PREREQ_PM への サポートされていません. MakeMaker 6.48 はバンドルされました Perl 5.8.9 で, より最近のバージョンは利用可能です CPAN で.

"How can I indicate that my distribution requires a version of Perl with threads?" ( どのように私は示しますか 私のディストリビューションがバージョンを要求することを スレッドを持つ Perl の ? )

The current paradigm is to allow thread-based modules to be installed on non-threaded Perls. As such, you should NOT put any such checks in your Makefile.PL, but should allow the module to be installed regardless.

現在のパラダイムは許可することです スレッドベースのモジュールを インストールすることを 非スレッドの Perl で. そのため, あなたはしないほうがよいです おくことを そのようなチェックを あなたの Makefile.PL に, しかし許可する必要があります モジュールがインストールされるように 関係なく.

The rationale for this is to allow modules/packages/applications to be developed and run on non-threaded Perls. For instance, threads::shared is available, but essential does nothing if used on non-threaded Perls (or in non-threaded applications). Thread::Queue similarly provides object-oriented FIFO queues on both threaded and non-threaded Perls.

これの根拠は できるようにすることです モジュール/パッケージ/アプリケーションを開発して実行することを 非スレッドの Perl で. 具体的には, threads::shared は利用可能です, しかし本質的には何もしません もし使われるなら 非スレッド Perl ( または 非スレッドアプリケーション ) で. Thread::Queue は同じく提供します オブジェクト指向の FIFO キューを 両方に スレッド化されたものと非スレッドの Perl に.

In your test suite, adding the following preamble to the top of any test files that 'use threads;' will keep them from generating failures:

あなたのテストスイートで, 追加して 次の前文を すべてのテストファイルの先頭に 'use threads;' の それらをキープします 失敗の生成から:

BEGIN {

  use Config;

  if(! $Config{'useithreads'}){

    print("1..0 # Skip: Perl not compiled with 'useithreads'\n");

    exit(0);

  }

}

Additionally, if possible, you should try to include tests that test your module's functionality in non-threaded applications (i.e., when 'use threads;'is not used).

加えて, もし可能なら, あなたはトライする必要があります テストを含めることを テストする あなたのモジュールの機能を 非スレッドアプリケーションで ( i.e., 'use threads;' が使われないとき ).

You also don't need to put in special checks for the 'threads' module in your module's code. Just using 'use threads;' will cause the following error message to occur:

あたなはまた置く必要はありません 特別なチェックを 'threads' モジュールのための あなたのモジュールのコードで. ただ使うだけで 'use threads;' を 要因になります 次のエラーメッセージが起こる:

The Perl not built to  support threads

"How can I indicate that my distribution only works on a particular operating system?" ( どのように私は示しますか 私のディストリビューションが特定のオペレーティングシステムのみで動作することを ? )

While it isn't a very elegant solution, the recommend approach is to either die in the Makefile.PL or Build.PL (or BAIL_OUT in a test file) with one of the following messages:

とてもエレガントな解決策ではないものの, 推奨されるアプローチは いずれかで die することです Makefile.PL or Build.PL ( または BAIL_OUT test ファイルの ) の 次のメッセージのひとつとともに:

・No support for OS
・OS unsupported

・ サポートされていない OS
・ OS はサポートされていない

CPAN Testers tools will look for one of those phrases and will send an NA (Not Available) report for that platform.

CPAN Testers ツールは探します これらのフレーズのひとつを それと 送信します NA ( Not Available ) リポートを そのプラットフォームのための.

Devel-AssertOS is an experimental tool that you can bundle with your distribution in an inc/ directory and use in your Makefile.PL or Build.PL to die with the appropriate message if not on a supported OS:

Devel-AssertOS は実験的なツールです あなたはバンドルできます あなたのディストリビューションと inc/ ディレクトリで それと 使います あなたの Makefile.PL or Build.PL で die に 適切なメッセージでの サポートされていない OS だった場合に:

# in a Makefile.PL or Build.PL

use lib 'inc';

use Devel::AssertOS qw(Linux FreeBSD Cygwin);

"How can I stop getting FAIL reports for missing libraries or other non-Perl dependencies?" ( どのように私は停止しますか FAIL リポートを ライブラリが見つからないや他の非 Perl 依存関係の ? )

If you have some special dependencies and don't want to get CPAN Testers reports if a dependency is not available, just exit from the Makefile.PL or Build.PL normally (with an exit code of 0) before the Makefile or Build file is created.

もしあなたが持っていて いくつかの特別な依存関係を 望まないなら CPAN Testers リポートの取得を 依存関係が利用できない場合に, ただ出るだけです Makefile.PL or Build.PL から 普通は ( 0 の exit コードで ) Makefile or Build ファイルが作成される前に.

exit 0 unless some_dependency_is_met();

Devel-CheckLib is an experimental tool that you can bundle with your distribution in an inc/ directory and use in your Makefile.PL or Build.PL to issue a warning and exit if a library is not available:

Devel-CheckLib は実験的なツールです あなたはバンドルできます あなたのディストリビューションと inc/ ディレクトリで それと 使います あなたの Makefile.PL or Build.PL を warning と exit を出すために ライブラリが利用できない場合に:

# in a Makefile.PL or Build.PL

use lib 'inc';

use Devel::CheckLib;

check_lib_or_exit(lib => 'jpeg');

See the documentation for instructions on specifying multiple libraries or specifying additional library paths to search.

参照します ドキュメントを 方法のために 指定する 複数のライブラリを または 指定する 追加のライブラリパスを 検索のための.

Never, ever, set the MakeMaker parameter PREREQ_FATAL to true, it is a flawed invention. Not only has it the effect that no Makefile is being written thus preventing installers to actually try to install prerequisites. It also exits with an error code, so that cpantesters would rate it as a FAIL.

何が, あっても, セットすることはありません MakeMaker のパラメータ PREREQ_FATAL を true に, それは欠陥のある発明です. それは効果を持っているだけではありません Makefile が書かれていないので 防止する インストーラーが実際にトライすることを インストールを prerequisites ( 前提条件 ) の (# (d093) ). それはまた終了します エラーコードで, なので cpantesters はそれを評価するはずです FAIL として.

(vkon: I think this is not fair. Tester is not even getting Makefile and already sends FAIL. This feature is largely un-useful, and this is a bug in tester's smoking scenario, IMO.)

( vkon: 私は考えます これはフェアではないと. Testers はゲットすらしていません Makefile を それと すでに送信しています FAIL を. この機能は 大部分が役に立たちません, それと これはバグです tester の smoking シナリオの, IMO ( # In My Opinion ). )

(dcantrell: some really old distributions have no Makefile.PL, so CPAN.pm makes one up. This is expected behaviour. Therefore having no Makefile is not a show-stopper. Generating failure reports for failures at Makefile.PL-time is desirable, as it will find bugs such as Makefile.PL requiring modules that aren't available)

( dcantrell: いくつかの本当に古いディストリビューションは Makfile を持っていません, なので CPAN.pm はそれを作ります. これは予期される振る舞いです. 従って Makefile を持たないのは ショーストッパー ( # 致命的な問題 ) ではありません. 生成することは failure リポートを 失敗のために Makefile.PL-time での 望ましいことです, 見つけるので バグを Makefile.PL が必要とする 利用出来ないモジュールのような )

"How should I invoke perl from my test scripts?" ( どのように私は呼び出すべきですか perl を 私のテストスクリプトから ? )

If you don't want to add any extra dependencies:

もしあなたが望まないなら 追加を 何か余分な依存関係の:

use Config;

my $path_to_perl = $Config{perlpath};

# now exec/system/qx/whatever using that variable

or use the Probe-Perl module. Perl might not be in the path, or your user might have several different version of perl installed, so using either of these methods instead of just using what you hope is the right version of perl will ensure the test is run with the appropriate perl binary.

または使用します Probe-Perl モジュールを. Perl は path にないかもしれません, または あなたのユーザはいくつか異なるバージョンをもっているかもしれません インストールされた perl の, なので 使いますいずれかを これらのメソッドの ただ使う代わりに あなたが望む正しいバージョンを perl の 確実にテストを実行するように 適切な perl バイナリで.

Probe::Perl is a more correct choice, as it gets things right under some edge-cases. But it does add another dependency to your code.

Probe::Perl は より正しい選択です, 得られるので 正しい物事を いくつかのエッジケースで. しかしそれは追加します ほかの依存関係を あなたのコードに.

This page used to recommend use of $^X. That's still better than just system("perl blahblahblah"), but situations where $^X may be wrong include:

このページは推奨しています 利用を $^X の. それはまだベターです ただのシステム ( "perl blahblahblah" ) よりも, しかし シチュエーションは $^X が間違っているかもしれない 含みます:

・perl was executed with a relative path and the script has chdir()ed;
・because $^X originates in C's argv[0] (in the main() function) it is possible for the calling program to exec() in such a way that argv[0] isn't the path to the interpreter;
・HP/UX can do weird stuff in scripts that use #!
・VMS

・perl が実行された 相対パスで それと スクリプトが chdir() された;
・$^X は由来するので C の argv[0] ( main() 関数の ) に それは呼び出すことができる プログラムを exex() に といったやり方でも argv[0] が path ではない インタプリタへの;
・ HP/UX はできる 変なことを スクリプトで 使う #! を.
・ VMS ( # Virtual Memory System )

"Why am I being told 'Can't locate Devel/Autoflush.pm in @INC'?" ( なぜ私はいわれますか 'Can't locate Devel/Autoflush.pm in @INC ? と )

CPAN::Reporter sets PERL5OPT="-MDevel::Autoflush" to ensure Makefile.PL or Build.PL prompts are always visible. This error will show up when your tests or code execute 'perl' instead of $^X and the default perl in $ENV{PATH} does not have Devel::Autoflush installed. See the prior question on how to invoke perl safely.

CPAN::Reporter はセットします PERL5OPT="-MDevel::Autoflush" を 確実に Makfile.PL または Build.PL プロンプトが 常に表示されるように. このエラーは見せますあなたのテストまたはコードが実行して 'perl' を $^X の代わりに それと デフォルトの perl が $ENV{PATH} の 持っていないときに Devel::Autofulsh を インストールされた. 参照します 前の質問を perl を安全に呼び出すやり方での.

"How can I get more detail about a failing test script?" ( どのように私は取得しますか より詳細を 失敗したテストスクリプトについての ? )

If the Test::Harness output in the CPAN Testers report is insufficient, you could email the tester and ask for a more detailed output to help diagnose your test failure. (See answers to "How do I contact a tester?" below.)

もし Test::Harness の出力が CPAN Testers リポートでの 不十分なら, あなたはできます tester に email を それと 求めることを より詳細な出力を 診断を助けるための あなたのテストの失敗の. ( 参照します 回答を "How do I contact a tester?" への 下の. )

About CPAN Testers reports ( CPAN Testers リポートについて )

"Comparing the fast-matrix web page with the non-fast matrix web-page" ( 比較 fast-matrix ウェブページと非 fast matrix Webページの )

Q: Why do these two not show the same information: http://fast-matrix.cpantesters.org/?dist=MarpaX-ESLIF%202.0.14 'v' http://matrix.cpantesters.org/?dist=MarpaX-ESLIF%202.0.14?

Q: なぜこれら 2 つはするのですか 同じでない情報をみせることを: http://fast-matrix.cpantesters.org/?dist=MarpaX-ESLIF%202.0.14 'v' http://matrix.cpantesters.org/?dist=MarpaX-ESLIF%202.0.14?

A: (Quoting Doug Bell [preaction]): Slaven would have to answer definitively, but fast-matrix isn't necessarily guaranteed to be accurate. It's not supposed to be. It's supposed to be fast. Matrix uses the fully-processed CPAN Testers data, which has been built to ensure that no data is lost between the Metabase and the website. Fast-matrix polls an API that displays the last 1000 reports (which opens it up to potentially missing data if a lot of data comes in too quickly). There's also the possibility that fast-matrix validates SSL to the Metabase and couldn't connect while the SSL cert for metabase.cpantesters.org was expired.

A: ( 引用する Doug Bell [preaction] ): Slaven は答えなければならないでしょう 確実に, しかし fast-matrix は必ずしも保証しません 正確であることを. それはないと思われます. それは速くなると思われます. Matrix は使います 完全に-処理された CPAN Testers データを, それは構築されています 確実に そのデータが失われないように メタベースとウェブサイトの間で. Fast-matrix は polls ( # ポーリング ? ) します 表示する 過去 1000 のリポートを ( それは開きます 失われた可能性があるデータまで もし たくさんのデータが来ると とても速く ). また可能性があります fast-matrix は検証して SSL を メタベースへの それと 接続できなかった 間に SSL 証明書が metabase.cpantesters.org のための 失効している.

In short, it sounds normal to me, but Slaven would have to answer definitively.

要するに, それは普通とおもいます 私には, しかし Slaven は答えなければならないでしょう 確実に.

"Why am I getting these reports?" ( なぜ私は取得しますか これらのリポートを ? )

The short answer is that you uploaded a distribution, via PAUSE, to the CPAN. The longer answer is that the CPAN Testers will test your distribution on their system, once PAUSE announces it has been indexed. They will run your test suite and submit reports on the outcome. If you have received one of these reports, it is likely that the test suite doesn't exist or cannot be found (UNKNOWN) or one or more of the tests in the test suite failed (FAIL).

短い答えは あなたがアップロードしたことです ディストリビューションを, PAUSE を介して, CPAN に. 長い答えは CPAN Testers はテストするということです あなたのディストリビューションを 彼らのシステムで, するとすぐに PAUSE はアナウンスします それがインデクスされたと. 彼らは実行します あなたのテストスイートを それと 提出します リポートを その結果の. もしあなたが受信したなら リポートのいずれかを, それは かもしれません テストスイートが存在しない または 見つからない ( UNKNOWN ) または ひとつ以上が テストの テストスイートでの 失敗した ( FAIL ).

"Can't CPAN Testers read? I have detailed the format I require for bug reports!" ( CPAN Testers は読むことはできませんか ? 私は持っています 詳細なフォーマットを 私が必要とする バグリポートのために )

Please do not get irate with CPAN Testers. They are there to try and help you. The reports they send are often automated, without any human intervention, and are simply the output of your own test suite. If you want the testers to produce something special, it is suggested you include test scripts that include all the necessary diagnostic information you will need to understand why your distribution failed.

怒らないでください CPAN Testers に. 彼らは手伝うつもりでいます あなたを. リポートは 彼らが送信した 多くは自動化されています, 人間の介入なしに, それと 単なる出力です あなたの独自のテストスイートの. もしあなたが望むなら テスターが作成することを なにか特別なものを, 推奨しています あなたが含めることを テストスクリプトを それは含みます すべての必要な診断情報を あなたが必要とする 理解するために なぜあなたのディストリビューションが失敗したのかを.

If you ask nicely, I'm sure the tester who tested your distribution will try and help you solve the problem. Rejecting reports simply because they don't meet your expectations of what a bug report should look like does you no favours. Users often read the CPAN Testers website to see whether a distribution fails on a particular platform or perl combination. Ignoring that will only mean your distribution gets less usage than it might otherwise gain.

もしあなたが良い感じに尋ねれば, 私は確信します テスターは テストした あなたのディストリビューションを あなたを手伝うと 問題を解決する. リポートの拒絶は 単純な理由での それらがあなたの期待に合わないという バグリポートのようにみえる あなたに都合よくはありません. ユーザはしばしば読みます CPAN Testers のウェブサイトを 見るために ディストリビューションが失敗するかどうかを 特定のプラットフォームまたは perl の組み合わせで. 無視することは それを あなたのディストリビューションが得ることのみを意味します 少ない使用量を そうでなければ得たかもしれないよりも.

"Why are you testing (and failing) my Tk-ish module without an X server?" ( なぜあなたはテストしますか ( そして失敗する ) 私の Tk-ish モジュールを X サーバなしで ? )

Until very recently, Tk wouldn't build without a display. As a result, the testing software would look at the test failures for your module and think "ah well, one of his pre-requisites failed to build, so it's not his fault" and throw the report away. The most recent versions of Tk, however, *will* build without a display - it just skips all the tests. So the testing software sees that it passed, and thinks there must be something wrong with your module. You should check for a working Tk (and hence X11) environment by checking if MainWindow->new() throws an exception:

ごく最近まで, Tk はビルドできませんでした ディスプレイなしで. 結果として, テスティングソフトウェアは見るでしょう テスト失敗を あなたのモジュールの それと考えます "ああ, ひとつが 彼の pre-requisites の 失敗した ビルドで, なので それは彼のまちがいではない" それと リポートを投げ捨てます. 最新のバージョンは Tk の, けれども, ビルド "するはずです" ディスプレイなしで - それはただスキップするだけです すべてのテストを. なので テスティングソフトウェアはそれがパスしたとみます, それと考えます それらは何か間違っているだろうと あなたのモジュールで. あなたはチェックする必要があります 動作している Tk ( したがって X11 ) 環境を 調べることで MainWindow->new() が投げているかどうかを 例外を:

my $mw = eval{ MainWindow->new };

if (!$mw ) { ... skip tests ... }

"Why am I getting a FAIL/UNKNOWN/NA report when prerequisites are not met?" ( なぜ私は取得しますか FIAL/UNKNOWN/NA リポートを prerequisites ( 前提条件 ) が満たされていないときに ? )

Some early versions of CPAN Testers tools had bugs that did not properly catch when prerequisites were specified but not met. Please just ignore these reports.

いくつかの初期のバージョンは CPAN Testers tools の バグを持っていました それは適切にキャッチしませんでした prerequisites ( 前提条件 ) が指定されて しかし 満たされていないときに. ただ無視してください これらのレポートを.

"How can I stop getting these reports?" ( どのように私は停止しますか 取得しているこれらのリポートを ? )

At the moment, the suggestion is to use a filtering mechanism in your mail client of choice. However, this may mean you miss valid reports from users, so you might want to filter reports into a dedicated mail folder and periodically check it, deleting anything you are not interested in. At the moment there is no way for you to tell testers that you don't wish to receive reports, although a mechanism is currently being considered, that would allow the author to include an appropriate entry in the META.yml file, which the testing mechanism could then respect.

今のところ, 提案は 使うことです フィルタリングメカニズムを あなたのメールクライアントで 好みの. しかしながら, これは意味するかもしれません あなたに 損なうことを 有効なリポートを ユーザからの, なので フィルタしたほうがよいでしょう リポートを 専用のメールフォルダに それと 定期的にそれをチェックして, 削除します あなたが関心のないものすべてを. 今のところ 方法はありません あなたがテスターに伝える あなたが望まないことを リポートの受信を, もっとも メカニズムが 現在検討されています, それは許します オーサーに 含めることを 適切なエントリを META.yml ファイルに, それでテスティングメカニズムを尊重できます.

"How can I get more of these reports?" ( どのように私はより取得しますか これらのリポートを ? )

Marcel Grünauer has written a script to fetch arbitrary reports: App::sync_cpantesters

Marcel Grünauer は書いています スクリプトを 取得する 任意のリポートを: App::sync_cpantesters

"Can I tell if my module is being tested by an automated client (a.k.a. 'smoker')?" ( 私に伝わりますか もし私のモジュールがテストされたら 自動化されたクライアント ( a.k.a 'somoker' ) によって ? )

Automated smoke testers should set $ENV{AUTOMATED_TESTING} to a true value. This allows authors to skip certain tests (or include certain tests) when the results are not being monitored by a human being.

自動化スモーク testers は セットするべきです $ENV{AUTOMATED_TESTING} を 真 の値に. これは許可します 著者がスキップすることを 特定のテスト ( または特定のテストを含む ) を 結果が監視されていないときに 人間によって.

One could even go so far as to halt building and testing a distribution under automated testing by exiting with zero at the top of the Makefile.PL or Build.PL file:

それはビルドを停止してディストリビューションをテストすることさえできます 自動化されたテストのもとで 終了することで Makefile.PL または Build.PL ファイルの先頭のゼロで:

exit 0 if $ENV{AUTOMATED_TESTING};

"How do I contact a tester?" ( どのように私はコンタクトしますか テスターと ? )

Most testers will Cc you on FAIL and UNKNOWN test results, so you can just reply to the email. But if you're looking at test results through, eg, a web page, then this tool will convert a test report number into the tester's email address.

ほとんどの testers は あなたに Cc します FAIL と UNKNOWN のテスト結果を, なので あなたはただ返信するだけです その email に. しかし もしあなたが見ているなら テスト結果を 通じて, eg, web ページ などを, そのときこのツールは変換します テストリポート番号を tester's email アドレスに.

"Should I write OS-independent code?" ( 私は書くべきですか OS に依存しない ( OS-independent ) コードを ? )

Yes, more or less always.

はい, 多かれ少なかれ 常に.

If you think you won't need it, I encourage you to discard that thought and reconsider.

もしあなたが考えるなら あなたはそれを必要でないと, 私はあなたに勧めます 捨て去ることを その考えを それと 再考することを.

There are cases, e.g. accessing the MS Windows registry, where you'd say the decision is obvious, but in general, I recommend you make the effort to write OS-independent code for 3 reasons:

ケースがあります, e.g. MS Windows のレジストリにアクセスする, そこであなたは言うでしょう決定は明らかだと, しかし一般的には, 私は推奨します あなたが努力することを OS から独立したコードを書く 3 つの理由で:

・You are training yourself as to how to write high(er) quality code.
・You're considering more carefully how you're actually using directories and files.
・You are providing a guideline for users and readers of your code.

・あなたはトレーニングしています あなた自身を どのように書くかについて (より) 高い品質のコードを.
・あなたは考慮しています より慎重に どのようにあなたが実際に使っているか ディレクトリとファイルを.
・あなたは提供しています ガイドラインを ユーザと読者のために あなたのコードの.

"Are there any traps in writing OS-independent code?" ( 何かトラップはありますか 書くにあたり OS に依存しないコードを ? )

Yes, many. Next I discuss some related to directory and file management.

はい, たくさん. 次で私は論じます 関連したいくつかを ディレクトリとファイルの管理に.

"What are the problems with temporary directories?" ( 何が問題ですか 一時ディレクトリの ? )

Firstly, I'll assume you want to write to this directory, or a file within it, even if you only want to write zero bytes in order to use it as a present/absent flag.

第一に, 私は仮定します あなたが望むと 書き込みを このディレクトリ, またはファイルに その中の, たとえあなたが書き込みのみを望むとしても ゼロバイトの 使うために 在/不在 のフラグとして.

You can't assume the OS is Linux and you can't assume the temp directory is '/tmp'.

あなたは仮定できません OS が Linux だと それと あなたは仮定できません 一時ディレクトリが '/tmp' だと.

Also, you need to ask: Do I want /a/ temp directory or /the/ temp directory?

また, あなたは尋ねる必要があります: 私は必要ですか /a/ temp ディレクトリ or /the/ temp ディレクトリが ?

File::Spec will find /the/ temp directory (as long as it's writable), or return the current directory.

File::Spec は見つけます /the/ temp ディレクトリを (それが書き込み可能である限り), または 返します 現在のディレクトリを.

my($temp_dir) = File::Spec -> tmpdir;

Is that what you want? If so, problem solved - perhaps. But keep reading.

それはあなたが望むものですか ? もしそうなら, 問題は解決しました - おそらく. しかし読み続けてください.

However, let's look for /a/ temp directory:

しかしながら, 見て見ましょう /a/ temp ディレクトリを:

my($temp_dir) = File::Temp -> newdir; # Bad code! Do not use!

                                         # 悪いコード! 使わないで!

Note: This is an alternative to File::Temp's function tempdir(). Don't use that one either!

注意: これは代替です File::Temp のファンクション tempdir() の. 使用しないでください どちらも !

But what's the problem, I head you cry?

しかし 何が問題なのか, 私はあなたを泣かせますか ?

You've fallen for the trap of assuming your end user is not running FreeBSD. You don't know that!

あなたは罠に落ちました 仮定することの あなたのエンドユーザが FreeBSD を実行していないと. あなたはそれを知りません !

And no, it's not true that FreeBSD's nick is The World of Pain :-), but sometimes it feels like it.

それと いいえ, 真実ではありません FreeBSD のニックネームが The World of Pain というのは :-), しかし時々そのように感じます.

Don't get me wrong - I thank CPAN testers for using FreeBSD, since it's taught me to be much more careful about directory and file handling.

誤解しないでください - 私は感謝します CPAN testers に 使っている FreeBSD を, わたしに教えてくれたので もっと慎重であるように ディレクトリとファイルの取り扱いについて.

The problem is that to deal with all OSes, including FreeBSD, you need this:

問題は すべての OS に対象するには, FreeBSD を含む, あなたはこれが必要だということです:

my($temp_dir) = File::Temp::newdir('temp.XXXX', CLEANUP => 1, EXLOCK => 0, TMPDIR => 1);

Here, the EXLOCK is the most important flag, but we might as well be thorough and use all those options. Consult the docs for the details. I'm not spoonfeeding you everything.

ここでは, EXLOCK が最も重要なフラグです, しかし私たちは 徹底することもそれらのオプションを全て使うこともできます. 参考にしてくださいドキュメントを 詳細のために. 私はスプーンフィーディングしていません あなたに すべてを.

And yes, you really do need that EXLOCK option.

もちろん, あなたは本当に必要です その EXLOCK オプションが.

"OK. So what do I need to know about temp files?" ( OK. では私は何を知る必要がありますか 一時ファイルについて ? )

Not so fast! You haven't checked that your temp directory is writable.

急がないでください ! あなたはチェックしていません あなたの一時ディレクトリが書き込み可能かを.

Some CPAN testers run with the temp directory set to read-only. So, check and double-check.

一部の CPAN testers は実行します 一時ディレクトリをセットして 読み込み専用に. なので, チェック アンド ダブルチェックです.

And by that I mean, write the code that checks /after/ deciding what you're going to do if you determine that you can't write to $temp_dir (assuming still that you want to).

それとそれによって私が意味するのは, コードを書くことです チェックする 決めたあとで あなたが何をするか もしあなたが判断した場合に あなたが書き込めないと $temp_dir に (仮定して まだ あなたがそれを望んでいると).

Most likely, you'll call BAIL_OUT(), the escape hatch built into Test::More.

もっともありそうなのは, あなたは呼び出します BAIL_OUT() を, エスケープハッチの Test::More に組み込まれている.

Errr, you are using Test::More, right? Phew.

ええっと, あなたは使ってますよね Test::More を, でしょ ? ふう.

"OK. Now what do I need to know about temp files?" ( OK. 今私は何を知る必要がありますか 一時ファイルについて ? )

Fundamentally, make the directory separator OS-independent with:

根本的に, ディレクトリセパレータは OS に依存しないようにします:

my($path) = File::Spec -> catfile(@directories, $filename);

Here, @directories is probably just $temp_dir from above, but may not be.

ここで, @directories は おそらくただの $temp_dir です 上記の, しかしそうでないかもしれません.

Of course, there are packages build on top of File::Spec, such as Path::Class. However I've found that in testing code I virtually never need an object to represent a directory or file, so I rarely use Path::Class. But it's good to know it's available.

もちろん, パッケージがあります 上にビルドされた Fiel::Spec の, Path::Class のような. しかしながら 私は見つけたので テストするコードでは 実質的に決して必要ではないことを オブジェクトが ディレクトリまたはファイルを表す, なのでめったに使いません Path::Class を. しかし知っておくことはグッドです それが利用可能だと.

"Are there any other directory/file matters I need to be aware of?" ( 何か他にディレクトリ/ファイルの事柄はありますか 私が認識しておく必要がある ? )

Yes indeed. Let's consider all the problems to do with a file with a fixed name.

はいそうです. 考慮しましょう すべての問題を 固定された名前で行う.

An example of this would be session management with a module such as Data::Session. In particular, if you opt for Data::Session::ID::AutoIncrement to provide a sequence of IDs, it's default file name is:

この例は セッションマネージメントになります モジュールでの Data::Session のような. 特に, もしあなたが Data::Session::ID::AutoIncrement を選択して 提供するなら 一連の ID を, そのデフォルトのファイル名は:

File::Spec -> catdir(File::Spec -> tmpdir, 'data.session.id').

Look familiar? Good. But here we're worried about the last component, 'data.session.id'.

見覚えがありますか ? グッド. しかしここでは心配です 最後のコンポーネント, 'data.session.id' が.

What could go wrong? Well, it's assuming that:

何がうまくいかないでしょうか ? えっと, それは仮定してます:

・File::Spec -> tmpdir always returns the same directoru.
・The owner of the file is always the same user.

・File::Spec -> tmpdir は 常に返します 同じディレクトリを.
・ファイルのオーナーは 常に同じユーザです.

The first point's pretty safe (I hope), so let's concentrate on the second point.

最初のポイントはとても安全です ( 私は願います ), なので集中しましょう 2 番目のポイントに.

Since the CGI script (assuming that's the environment we're working it) is probably always run as the same user, we assume we should be able to access this file.

CGI スクリプト ( 仮定しています その環境を 私たちが作業しているそれと ) は たぶん常に実行できるので 同じユーザとして, 私たちは仮定します 私たちはアクセスできるはずだと このファイルに.

But is that true? Hint: The correct answer is: No, it's not always true.

しかしそれは真実ですか ? ヒント: 正しい答えは: いいえ, それは常に真実というわけではありません.

For instance, the main web server may be Plack or Apache, run by a special user called, e.g. nobody or (under Debian) www-data. Or perhaps you're running Engine X (nginx), and the user is nginx.

具体的には, メイン web サーバは Plack or Apache かもしれません, 実行する スペシャルユーザによって 呼ばれる, e.g. nobody or ( Debian のもとでは ) www-data と. または ひょっとして あなたは実行しています Engine X ( nginx ) を, それと ユーザは nginx です.

The problem arises when you're testing and running code as yourself, or in the process of switching web servers, or proxying to a different web server rather than just another copy of the same web server running on a different port.

この問題は生じます あなたがテストして それと 実行しているときに コードを あなた自身で, または 切り替えるプロセスで web サーバを, または プロキシするとき 異なる web サーバを ただの他のコピーではなく 同じ web サーバの 実行している 異なるポートで.

Of course I expect you'll be on a different machine, but the other possibilities are real.

もちろん私は期待します あなたが異なるマシンにいることを, しかし 他の可能性は現実的です.

"So how do I handle such a situation?" ( では私はどのように処理しますか そのような状況を ? )

See also the next question.

また参照します 次のクエスチョンも.

Provide the session management code with a file name, and here it'd be:

提供します セッション管理コードを ファイル名で, それと ここではこうなります:

Data::Session::ID::AutoIncrement -> new(id_file => '...');

which is passed in, when you create a new session object, via:

それは渡されます, あなたが作成するときに 新しいセッションオブジェクトを, 介して:

Data::Session -> new(id_file => '...');

This is the best solution - or arrange for the web servers to all run as the same user.

これはベストソリューションです - またはアレンジします web サーバががすべて実行されるために 同じユーザとして.

There may be other solutions. But that's not the point.

他のソリューションもあるかもしれません. しかし それはポイントではありません.

The point is to be aware of what's happening behind the scenes, and to code defensively. Hence your motto: Check and double-check.

ポイントは 認識することです 何が起こっているかを 舞台裏で, それと ディフェンシブにコード化することです. したがってあなたのモットーは: チェック アンド ダブルチェックです.

"What else can I try?" ( 何か他に 私はトライできますか ? )

Use File::HomeDir. This may, repeat may, solve your problem.

使います File::HomeDir を. これはひょっとすると, 繰り返し, 解決するかもしれません あなたの問題を.

Since by now we're using a per-user directory, we've circumvented the problem of multiple users competing for a file with a fixed name.

今では私たちは使っているので ユーザ毎のディレクトリを, 私たちは迂回しています 問題を 複数のユーザが競合することを 固定された名前のファイルで.

File::HomeDir has a method called my_data() which looks like a candidate to help, and my_dist_data(), which looks like an even better one. So let's settle on my_dist_data().

File::HomeDir は持っています メソッドを my_data() と呼ばれる 候補者のように見える 助けるための, それと my_dist_data() を, より良いものに見える. なので 解決しましょう my_dist_data() で.

Now we have these questions to deal with:

今私たちは持っています これらの質問を 対処すべき:

・Does the current user have a home directory?

・現在のユーザは持っていますか ホームディレクトリを ?

No, not always. CPAN testers, e.g., sometimes run with users without home directories. So check.

いいえ, 常にというわけではありません. CPAN testers は, e.g., ときどき実行します ユーザで ホームディレクトリなしの. なのでチェックします.

・If I use the create option to my_dist_data(), does it actually find or create the directory?

もし私が使うと create オプションを my_dist_data() に, 実際に見つかる または 作成しますか ディレクトリを ?

Not necessarily. So check.

必ずではありません. なのでチェックします.

・If so, is the directory writable?

もしそうなら, ディレクトリは書き込み可能ですか ?

Not necessarily. So check and double-check.

必ずではありません. なので チェック アンド ダブルチェックです.

Each of these needs to be checked, and if all turns out well, use that directory.

これらのそれぞれをチェックする必要があります, それと もしすべてがうまくいくなら, そのディレクトリを使います.

If not, BAIL_OUT().

もしそうでないなら, BAIL_OUT() (脱出, 救済 ) です.

Some providers are buggy and do not want to change it

いくつかのプロバイダはバギーで変更はしたくありません

sub inexistent_domain_do_not_resolve {

  use Socket;

  return 1 unless inet_aton('some.non.existent.host.');

  return 0;

}

# returns 1 if works correctly



if (inexistent_domain_do_not_resolve()) {

}

NEXT

次回は、この記事だけではわからない CPAN Testing の概要を知るために「 CPAN Testers Wiki 」の他の記事を確認する予定です。


参考情報は書籍「 続・初めての Perl 改訂版 」, 「 Effective Perl 第 2 版 」を中心に perldoc, Wikipedia および各 Web サイト。それと詳しい先輩。

目次 - Perl Index