※このエントリはPerlアドベントカレンダー2018の5日目のエントリとなります。
CPAN(MetaCPAN)でモジュールを公開するということ
Perlでプログラムを書くことに慣れてくると、CPANモジュールを使うようになったり、もっと慣れてくると自分でPerlモジュールを作るようになり、最終的にはCPAN(今はMetaCPANですね)で公開するようになるかもしれません。私は過去にそのような道を歩んできました。
では私は過去にどんなモジュールを書いたのか。ひとまずMetaCPANに上がっているものを一部挙げると、 Otogiri(これはほとんど@tsucchiさんの力です), XML::Diver, Net::Azure::CognitiveService::Faceなどがあります。
PerlモジュールをMetaCPANで公開する前に
しかしながら、MetaCPANでモジュールを公開する前に気にかけておいて欲しいこととして、個人的には以下のような項目を挙げたいと思います。
- そのモジュールを公開することで不快感を感じる人々が生じないか
- そのモジュールはセキュリティ的に致命的な問題を抱えていないか
- そのモジュールは新しい機能を提供してくれるか
- そのモジュールはプログラミング体験をより幸せにしてくれるか
- そのモジュールは従来の類似モジュールよりもパフォーマンスに優れるか
- そのモジュールは従来の類似モジュールよりも依存性が削減されているか
もし上記について該当するかわからない場合は、ひとまずgithubに上げておきつつ、ブログやTwitter等で言及してみましょう。運が良ければ誰かが注目してくれて、レビューをしてくれるかもしれません。これらのことは、Perlモジュールの公開に及び腰になってしまわない程度に、気をつけるとよいのではないでしょうか。
CPANの歴史を少しだけ垣間見る
では、なぜこのように自律する必要があるのでしょうか。それを知るためには過去に目を向けることが重要です。
歴史を振り返ると、charsbarさんによるエントリでCPANは幼稚園児の砂場じゃないよねという、2008年当時、大変考えさせられたものがあります。若い方の中にはこのような歴史を知らない方もいると思いますが、是非とも同じ轍を踏まぬための知識として、知っておいていただければ幸いです。
また、まかまかさんによるPerl同人誌「Acme大全」には、「Acme大全2012」から毎回、巻末付録として「とあるAcmeモジュールの削除について」という章が設けられています(ブログにも同様のエントリがある)。
このように、MetaCPANへモジュールを公開する上では、ある程度その性質を律せられる側面があることは間違いないでしょうし、誰かがつらい思いをしないためにも必要なことであると私は思います。
それでも日の目を見ないモジュールもある
そんな事もあって、実際にはたくさんのPerlモジュールを作っていたとしても、実際にMetaCPANにて公開されるものはその一部でしかありません。ほかにもMetaCPANに公開するのが怖いとか、作者がそこまでの有用性を感じていないだとか、謙遜している、などの理由でMetaCPANで公開されていないPerlモジュールがGithubにはあります。
このようにあえてGithubでの公開にとどめられているPerlモジュールを、私は親しみを込めてGithub止まりモジュールと呼んでいます。
そして今回紹介するGithub止まりモジュールは、拙作のTest::Procです。
Test::Proc – プロセスを起動し、その起動状態をテストする
Test::Procは5年前にGithubにpushされています。今となっては当時の記憶を頼りに解説する他ないという点がいささか不安です。
さて、Test::Procが目指したところは、テストスクリプトでプロセスの起動状態をテストしたいというものでした。
使い方はSYNOPSISにある通りです。(done_testingが抜けていたので、補足してあります。)
use Test::More;
use Test::Proc;
my $proc = test_proc 'my_task' => sub {
print 'test';
warn 'dummy';
sleep 20;
};
$proc->is_work;
$proc->stdout_like( qr/\Atest/ );
$proc->stderr_like( qr/\Adummy/ );
$proc->exit_ok;
done_testing;
あら捜し
レポジトリを見てみると、テストの少なさが気になります。github止まりモジュールにはよくある話かもしれないですが、だいぶ控えめなテストの数だなと感じますね。
そしてインターフェースが片手落ちです。というのも、このTest::Procはtest_proc
というDSLを提供しており、Test::Proc::Objectインスタンスを返しているのですが、test_proc
側にはクロージャ以外でプログラムを起動する方法が提供されていません。Test::Proc::ObjectはProc::Simpleのサブクラスであり、24行目で引数の$codeを実行しているので、Proc::Simpleのインターフェースを見る限り、文字列で外部コマンドとオプションを渡すことができるはずです。
実験
実際に以下のようなテストを作って実験してみました。
$ cat hoge.sh
sleep 3
echo "hoge"
$ cat t/12_shell.t
use strict;
use Test::More;
use Test::Proc::Object;
my $proc = Test::Proc::Object->new('sleep 3 sec. Then print "done"', 'bash ./hoge.sh');
$proc->is_work;
$proc->exit_ok;
$proc->isnt_work;
$proc->stdout_like(qr/\Adone\z/);
$proc->stderr_like(qr/\A\z/);
done_testing;
これを実行すると、以下のようになり、テストは成功します。
$ perl -Ilib t/12_shell.t
ok 1 - process sleep 3 sec. Then print "done" is work
ok 2 - process sleep 3 sec. Then print "done" exit code is 0
ok 3 - process sleep 3 sec. Then print "done" is not work
ok 4
ok 5 - process sleep 3 sec. Then print "done" STDERR like (?^:\A\z)
1..5
深掘りしていく
上記のことから、test_proc
にコマンドを文字列渡しして起動させることができそうですが、実際に以下のようなテストを試してみると、失敗してしまいます。
$ cat t/13_shell-with-test_proc.t
use strict;
use Test::More;
use Test::Proc;
my $proc = test_proc 'my_work' => 'bash ./hoge.sh';
$proc->is_work;
$proc->exit_ok;
$proc->isnt_work;
$proc->stdout_like(qr/\Adone\z/);
$proc->stderr_like(qr/\A\z/);
done_testing;
$ perl -Ilib t/13_shell-with-test_proc.t
Type of arg 2 to Test::Proc::test_proc must be sub {} (not constant item) at t/13_shell-with-test_proc.t line 5, near "'bash ./hoge.sh';"
Execution of t/13_shell-with-test_proc.t aborted due to compilation errors.
これはtest_proc
のインターフェースが($&)
となっているために起こっている問題となります。ですのでこれを($$)
としてあげると、以下のように成功します。
$ perl -Ilib t/13_shell-with-test_proc.t
ok 1 - process my_work is work
ok 2 - process my_work exit code is 0
ok 3 - process my_work is not work
ok 4
ok 5 - process my_work STDERR like (?^:\A\z)
1..5
なぜgithub止まりなのか
このように、完成度の低さゆえにgithub止まりとなっているTest::Procですが、その他に大きな理由として、私個人が出くわす状況にそもそもテストスクリプトでプロセスの起動状態をテストしたいケースがあまりにも少ないという点が挙げられます。
そういうわけで、結局あまり洗練もされないまま5年もgithub止まりとして塩漬けになっていたというわけです。
Test::Procの今後
一応、ユースケース的に「いいじゃん?」って思ってくれる人がいらっしゃるのであれば、forkしてshipitするまでやってくだされば良いとおもいますが、今の所私自身がなにかをするということは無いでしょう。
コンセプトモデルということでここはひとつ、ご理解いただければ幸いです。
まとめ
ざっくりまとめると以下のようになります。
- MetaCPANでPerlモジュールを公開する前に、いま一度そのモジュールの性質を見つめ直そう
- Perlコミュニティの歴史から、誰かがつらい思いをしないための行いについて知ろう
- Test::ProcというPerlモジュールを作ったけど、ユースケースに遭遇しなさすぎて結局Github止まりになった
- Github止まりモジュールは「コンセプトモデル」として見ると良さそうかも
明日のPerlアドベントカレンダーは6日目。@yoku0825さんによる「マイエスキューエルにはPerl Mongerが必要かもしれないはなし」です。