この記事はPerl入学式 Advent Calendar 2016の16日目の記事です。 どうも、こんにちはトーカナイザの守護霊ことマコピーです。Perl入学式には2013年からサポーターとして参加しています。最近はサポーターとしてはあまり出ていませんが、東京の懇親会にただ飲みに来るおっさんとして活躍しています。 CPANとは Perlで実用的なアプリケーションを書く上で避けては通れないCPANの話をします。Rubyで言うrubygems、Pythonで言うpypi、Node.jsで言うnpmです。 例えば「なーんか適当なサイトの内容を取ってきたいなー」と思ったときにPerlだと標準でHTTPクライアントが同梱されていないので(追記: と思ったんですが、5.14からHTTP::Tinyがコアモジュールに同梱されていました。なので「HTTPとは・・・」みたいにはならないですね)、自分で「HT
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事はPerl Advent Calendar 2016の12日目の記事です。昨日はytnobodyさんの「YAPC::Hokkaido 2016 SAPPORO が楽しかったという話」でした。 吉祥寺.pmというPerlのような物のイベントをやっています、Magnolia.Kです。 先日開催した吉祥寺.pm9で、CPAN Authorになった話のLTが有ったのと、最近色々な言語を使ってみて改めてCPANいいなーって思ったので、「CPANいいよね！」って話を書きます。 改めて、CPANいいよね！ PerlユーザーにはおなじみのCPA
『tl;dr』 http://d.hatena.ne.jp/charsbar/20080606/1212704287 『tl;dr』は甘え ここまで読んで意味がわかった方には、このポエムを読む必要などありません。読むだけ時間の無駄ですので、より創造的な活動に貴重な時間を費やしていただきたい。 え？どういうことｗ はい、此処から先は、上記の意味が解らなかった方向けにお届けする、自戒風個人的見解というジャンルのポエムです。 CPANにモジュールをリリースするということ 思うに、少なくとも以下のような意味があるはずです。 あなたの作ったモジュールが、cpanm一発でインストールできるようになる。 これはそのままで、単にcpanm Your::Moduleなどのようにすることでインストールできるようになることを指しています。 あなたの業務で当該モジュールを利用していた場合、確かにこれは如何にも便利
Hachioji.pm Advent Calendarもついに10日目. そんな2桁記念日に颯爽と登場したるはpapixです. 今日も宜しくお願い致します. 今日は時間がないので, 若干あっさり目で行きたいと思います. ...さて. 最近, Travis CIやCoverallsを使っている人が増えてきているような気がします. これらのサービスは, GitHubのリポジトリを結びつけておくと, 自動的にテストを回してくれたり, テストのカバー率を表示したりしてくれるのでとても便利です. 更に, GitHubのリポジトリ内のREADME.mdにこれらのバッヂを貼り付けておけば, README.mdの内容はリポジトリのトップページ(?)に表示されるのでこれらの状況をとても確認しやすくなります. ただ, Minillaでモジュールを管理している場合, README.mdはminil buildや
だいたいこのへんで教えてもらった話のまとめです。 http://lingr.com/room/perl_jp/archives/2013/04/03 CPANで名前空間を取るのは簡単です。今ならCPANに上げるコードベースの「どこか」に package Hoge; と書けば、CPAN Indexerにインデックスされていとも簡単にHoge名前空間のオーナーになれます。 (執筆時現在Hogeのオーナーはいません) これはlib/以下の.pmファイルやファイル先頭のpackage宣言だけに限った話ではありません。 例えば、example/MyApp.pmとかも対象です。 ちなみに誰がどの名前空間を持っているかは以下を見ることでわかります。 http://www.cpan.org/modules/02packages.details.txt 多くの場合この挙動に困ることはありませんが、以下の様な
tl;dr Module::Install::CPANfile を使う cpanfileのon ‘develop’セクションにModule::Install関連の依存を記述する .travis.ymlにinstall: cpanm --with-develop --installdeps --notest .を書く あらすじ 最近のModule::InstallでTravisるときの注意ポイント ってのがあるが、折角DSLなのに、BEGINに色々書くのは悲しかったが、今はcpanfileがあるので、Module::Install::CPANfileで解決できるよって話。 Module::Install::CPANfile を使う 依存関係をcpanfileに記述します。Makefile.PLからそのままコピペしてきて良いでしょう。featureとかはちょっと書き方が違ったりします。そもそも
CPANモジュールでサポートしていないOSのTest ReportをNA(Not Available)にしたい場合はMakefile.PLやBuild.PLで以下のようにする必要があります。 unless ($^O eq "MSWin32" || $^O eq "cygwin") { die "OS unsupported\n"; } CPAN Testersのツールは以下のメッセージを検出した場合に、NAとして扱います。 No support for OS OS unsupported また、Devel::AssertOSを使用することで同様のことが可能です。 See also: CPAN Authors FAQ
報告が大変遅くなってしまいってすいません＞＜ 去る 03/08 から 03/10 まで JPA (Japan Perl Association) の支援を受けて北海道に行って来ました。 以下が当日の資料に大幅に加筆修正を行ったものになります。 https://xaicron.github.io/slide/hokkaidopm-09/ じつは、北海道に行っている間はずっと風邪をひいていましたことをここに告白いたします。 が、そんなことはさておき、とにかく吹雪がすごくてなんというかテンションダダ上がりでござました。 飛行機が遅れてしまって、ホテルに着くのがだいぶ遅くなったんですが @techno_neko さんの寝坊好意により、タクシーで迎えに来てもらえることになり、無事に懇親会会場まで辿りつけました。 とりあえずついたらジンギスカンです。なにはともあれジンギスカン。そして地ビールがあるじゃ
https://github.com/toritori0318/p5-App-RedisTop/issues/5 issueを頂いて知ったのですが、 MANIFEST.SKIPに #!include_default を書いておくと デフォルトでMANIFESTから除外したほうがよいようなファイルを SKIPに追加してくれるようです。 blib/ pm_to_blib #!include_default こんな感じで書いておくと、make manifest の時に以下のように展開してくれる。 blib/ pm_to_blib #!start included /Users/toriitsuyoshi/perl5/perlbrew/perls/perl-5.16.2/lib/5.16.2/ExtUtils/MANIFEST.SKIP # Avoid version control files.
日ごとの CPAN module アップロード数を可視化してみた 日ごとの CPAN モジュールのアップロード数をHRForecastで可視化してみた。 感覚値としては5年ぐらい前より増えてる感じなんだけど、まあ実際そういう感じですね。
最近Perlのネガティブな話が話題ですが、ちょっとCPANまわりのサービスの自慢をさせてください。それは CPAN Testers です。 CPAN Testers *1 とは、CPANに公開したモジュールがどの環境で動きどの環境でどういうエラーがでるのかを集積するサービスです。 よく「Perl/CPANは枯れている」といいますが、それを支えているのはPerlの歴史とかPerlerの性格といった形のないものではなく、この CPAN Testers なのです。これがすごくいいんですよ。 特徴をざっと並べるとこんな感じ: Social testing service for CPAN Testerたちがモジュールを手元の環境でテストしてそのレポートをサーバに送る CPAN.pm のプラグインとしてレポートモジュールが存在する 同じ環境でもビルドオプションが違うパターンもあるので、自分ひとりで様
You’re a new CPAN author (congratulations!) or you have an old distribution that is about to be updated for the first time in years, and you find MYMETA.yml and MYMETA.json in your working directory that git or shipit warns about. You think: What are these files? Should I package these files? tl;dr — add MYMETA.yml and MYMETA.json to .gitignore and MANIFEST.SKIP (if you have one), and do not inclu
僕はもうちょっと Module::Install を使った方が良いのではないかと考えている、というお話 最近ちょっと話題だった、CPANモジュールのパッケージングの歴史 とか、あと twitter とか blog とか色々見てて思ったこと。 「Module::Install って、Plugin があるのがいいとこなんだけど、どのプラグインでどの関数が使えるのか分かんなくてハマるよね」、とか、「他にも罠多いし、その辺考えると、最近だと Module::Build 使った方が良くね？」ってのは、多分正論なんだけど、僕はちょっと違うんでないかな、と思っているという話。 Module::Install の長所は、「プラグイン」と「DSL」と言われることが多いのですが、僕は一番の利点は、「M::I 本体をインストールしなくても対象のモジュールをインストールできること」だと思います。この長所はコアモジ
最近同僚が次々とCPAN Authorになってて良い流れだなーとか思っています。 ただ、CPANへのモジュールの上げ方がわからないとか、M::Iを使えばいいのか M::Bを使えばいいのか、それらがそもそも何やってるのか分からないという話も 聞くので、僕自身もその辺の知識を整理してアップデートしました。 とりあえず、今はModule::Buildを使っておけば良いんじゃないかと 思っていますが、そこに至る歴史的経緯をまとめてみます。 大体、以下に書いてあることに加えて、最近の動きを書いています。 Module::Build：MakeMakerの後継者を目指して PerlでCPAN形式のモジュールを配布する場合は、Makefile.PLなりBuild.PLなりを モジュール作者が用意して、それがインストールに必要なファイル類を自動生成 するという流れになっています。 既存の雛形を使うと色々ファ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
