CPANモジュールは依存モジュールのバージョンを固定しない方がいい | おそらくはそれさえも平凡な日々
Perl界隈ではCarton周りのtoolchainが整ってきて「これからはsemantic versioningやー」みたいな意識が高まりそうですが、そういうルールに則ってバージョニングをするのは大いに結構だとは思うのですが、バージョン違いのモジュールを同一プロセスで共有するとかそういうことはPerlではできないのでどちらにせよ注意が必要です。 まあ、バージョン違いのモジュールを共有できたところで、バージョン違いのオブジェクトが変なところに渡って死ぬみたいな話もあったりなかったりするらしいので夢を見過ぎるのも良くないですね。 それとタイトルのとおりですが、CPANに上げるモジュールの場合はバージョンは固定したり最大バージョンを決めない方が良いでしょう。 例えば、 Super::ORM が Mouse 2.0に固定依存 Hyper::WAF が Mouse 3.0に固定依存 だったりすると
Current status this book, perl and me - 「CPANモジュールガイド」編集後記
YAPCも近いので近況書いてみようと思います :) ひさしぶりにログインしたけど、左上のネコかわいいっすね！ ぼくは今も VOYAGEGROUP という会社で働いてます。主にiOS向けのサービスをやる事業部にいますが、アプリサーバーはほとんどがperlで書かれたもの。バリバリ動いてくれてます。他にはPHPで書いたものもあるし、ObjCもさわるし、バッチとかもろもろ含めるとnodeやらrubyとかpythonとかいろいろ雑食に使ってます。 perlについて言うと、執筆当時なかったのは http://metacpan.org。今はほぼ cpan.org の代わりに使うようになりました。特に良いなと思うのは+1機能で、これのおかげでもはや全 cpan update を見る苦行せずとも、最近の++された一覧や、もっとサマライズされた http://niceperl.blogspot.jp/ の週刊
Perl 5.18 時代における Core module についての捉え方について - tokuhirom's blog
Perl 5.20 で、CPANPLUS とその依存モジュールたちが core distribution から分離されます。 また、5.22 では CGI.pm と Module::Build が分離されそうです。 ここにいたり、Perl 5 の core distribution にはいっている、ということの意味が徐々にかわってきつつあります。 では、現在の状況はなぜおきているのかを考えてみましょう。 configure_requires の普及Perl 5.8.5 あたりの時代では、Module::Build などは core distribution にはいっていないと、つらかったわけですが、configure_requires が普及したことにより、インストーラを CPAN shell で自動的にインストールすることができるようになりました。 これにより Module::Build
Millaで呼吸をするようにgithubでperl モジュールを開発しcpanにアップする - Debuginfo
Module::Setupを使ってモジュール書くぞ、と思ってた矢先に CPAN モジュールの開発についての最近の風潮という@tokuhirom氏のブログのエントリを読みました^^;; minillaでもよかったのですが、全体像がわからなかったので今回は@miyagawaさんの秀逸なscreencastを参考にmillaを使ってみることにしました。 Milla, a Dist::Zilla profile that doesn’t suck (screencast) 基本的にscreencastそのままやればいいのです。 依存関係が沢山あって時間がかかるのでscreencastを見てる裏でcpanm Dist::Millaを走らせましょう $ cpanm Dist::Milla githubにpushするためにApp::phを使います。(Rubyistの人はhubも使えるようです。) $ c
CPANモジュールに含まれるファイルについて調べた - $shibayu36->blog;
おそらくはそれさえも平凡な日々: CPANモジュールのパッケージングの歴史 の話を見ていて、興味が湧いたというのと、CPANモジュールを作ってもそういうところは無視してしまっていたので、これは良くないと思い少しだけ調べた。 lib, bin, t, xt README, Changes, LICENSE Build.PL, Makefile.PL MANIFEST, MANIFEST.SKIP META.yml, META,json MYMETA.yml, MYMETA.json blib パッケージの歴史 先程も書いたけど、おそらくはそれさえも平凡な日々: CPANモジュールのパッケージングの歴史に非常によく説明されているので、これを見るのが一番手っ取り早い。 かなり適当にまとめると makeでビルドしよう ExtUtils::MakeMakerでMakefileを作ろう でも簡単なこと
最近使ってるモジュールの話 - Hokkaido.pm#9
自己紹介 twitter @xaicron works :DeNA CPAN https://metacpan.org/author/XAICRON 免責 本日発表する内容は、個人的な考えや意見であり、 所属する組織、会社とは一切関係ありません。 免責 本日発表する内容は、個人的な考えや意見であり、 所属する組織、会社とは一切関係ありません。 また、スピリチュアルトークはできません。 というわけで 今日は、最近使ってるモジュールの話とかを中心にまったりやっていこうと思います。 いきなり本題に入る前に 自分がどんなふうに使うモジュールを選んでいるのか CPAN モジュールの選定基準 2008年ごろ書かれたいい記事があります。 CPANソムリエになる方法 ざっくりまとめると 最終更新日時がふるいモジュールは危険 テストが超絶少ないモジュールは危険 バグレポート溜まってるモジュールは危険 って感
おそらくはそれさえも平凡な日々: CPANモジュールのパッケージングの歴史
最近同僚が次々とCPAN Authorになってて良い流れだなーとか思っています。 ただ、CPANへのモジュールの上げ方がわからないとか、M::Iを使えばいいのか M::Bを使えばいいのか、それらがそもそも何やってるのか分からないという話も 聞くので、僕自身もその辺の知識を整理してアップデートしました。 とりあえず、今はModule::Buildを使っておけば良いんじゃないかと 思っていますが、そこに至る歴史的経緯をまとめてみます。 大体、以下に書いてあることに加えて、最近の動きを書いています。 Module::Build：MakeMakerの後継者を目指して PerlでCPAN形式のモジュールを配布する場合は、Makefile.PLなりBuild.PLなりを モジュール作者が用意して、それがインストールに必要なファイル類を自動生成 するという流れになっています。 既存の雛形を使うと色々ファ
サイトのクローリングにはScrappyがすごくいいかもしれない - Perl勉強メモ アルパカDiary出張版
クローリング楽しいですよね！ perlで高速にクロールしたいのであればGunghoなど使うのがいいかもしれませんが、 基本手軽にやりたいことが多いので WWW::Mechanize+Web::Scraper という組み合わせでクロールするのが定番でした。 しかしたまたま Scrappy を知り、 少し触ってみたところすごくいいのではないか！？と思い 記事にしてみました。*1 基本系(crawlコマンドを利用する場合) my $scrappy = Scrappy->new; $scrappy->crawl('１．クロールするルートURL', '２．URLにマッチするパス' => { '３．コンテンツにマッチするxpath or CSSセレクタ' => sub { my ($self, $item) = @_; # ４．キューに追加 $self->queue->add($item->{href
OrePANがcoolすぎる - blog.nekokak.org
みなさんCPANモジュールの管理どうしてますか？ rpm? deb?いやーメンドクサイですね。 メンドクサすぎて日がくれます。 それにそんな一元管理の方法したらコンポーネントが複数ある場合、 簡単にmoduleのバージョンがupでいないじゃないですか。 so badですね。 いまだとperlbrewとextlibでコンポーネント毎にcpanモジュールを管理することが 大分と楽にはなりましたが、OSの差はどう仕様も無い！ 実際にサービスに撒くmoduleに関してはサービスのosで作ったperlbrew+extlibで管理していいとおもいますが、 localの開発環境が、MacOSとかだとすると激しくメンドクサイですね！ さらにextlibとかに入れてるバージョンと全く同じバージョンのモジュールを 手元のmacに入れるとか実は結構むずかしいんですよね。 Makefile.PLでバージョンを指定
Iterator::GruopedRange 0.02 Released - 日向夏特殊応援部隊
さて、ちょっとしたことからタイトルのようなモジュールを書いて見ました。Iterator::GroupedRange モジュールは簡単に説明すると、リストまたは別の(複数行ずつ返す)イテレータから指定行数分まとめて列挙するというモジュールです。 0.01 で SYNOPSIS を思いっきり間違えてたので、正しいものをこちらに。*1 use Iterator::GroupedRange; my @ds = ( [ 1 .. 6 ], [ 7 .. 11 ], [ 11 .. 25 ], ); my $i1 = Iterator::GroupedRange->new( sub { shift @ds; }, 10 ); $i1->next; # [ 1 .. 10 ] $i1->next; # [ 11 .. 20 ] $i1->next; # [ 21 .. 25 ] my $i2 = Ite
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
OrePANとcpanmでCPANの部分ミラーを作ってCPANモジュールを管理する - blog.nomadscafe.jp
これまでサービスで使うCPANモジュールの管理と言えばrpm/debパッケージが主流だと思いますが、最近ではperlbrewで使いたいバージョンのperlをインストールすることもあり、rpm/debでは対応できなくなってきています。 perlbrewのperlに対してプロジェクトが依存しているCPANモジュールを入れる際、 $ perlbrew switch perl-5.12.3 $ cd /path/to/MyProj $ perl Makefile.PL $ cpanm --installdeps . などと cpanm —installdeps が使えます。 しかし、これではサーバを新規セットアップするたびに、最新のモジュールが入ることになりサーバ間でモジュールのバージョンの差異が生まれる可能性があります。 そこで対応策として考えられるのが開発サーバで—installdepsを実行
OrePAN - yet another DarkPAN manager - tokuhirom's blog
https://github.com/tokuhirom/OrePAN This is yet another DarkPAN manager. It is highly depended for cpanm. I don't think about relationship for CPAN.pm. It only works with cpanm. Just type % orepan.pl --destination=/path/to/repository Foo-0.01.tar.gzThen Foo-0.01.tar.gz register to the repo, and it add to the 02packages.details.txt.gz. And... You can install Foo from repo! % cpanm --mirror-only --m
Re: Perlスクリプトの一行目には何と書くべきなのか - Islands in the byte stream (legacy)
Re: Perlスクリプトの一行目には何と書くべきなのか もしCPAN形式でスクリプトを配布するなら、それは#!/usr/bin/perlないし#!perlとするべきで、env(1)を使うべきではないと思います。 CPAN形式のディストリビューションでは、インストールするスクリプトのshebang行をインストール直前に修正し、正しいパスに書き換えてくれます。ただし、このルーチン*1はいまのところenv(1)を認識してくれません。つまり、env(1)を使った場合、インストールに使用したperlと実際に実行されるperlが一致するとは限りません。perlを一つしかインストールしていないシステムなら、これでも問題なく動きます。しかし最近では、システムにインストールしてあるperlには触らず、アプリケーション用のperlを別途perlbrewなどでインストールしてそちらを使うということもよく行われ
異なるDBMS間のSQLを変換してくれるモジュール SQL::Translator - Perl勉強メモ アルパカDiary出張版
こういうの無かったらつくってみようかなーと思ったんですが、やっぱりありましたね。 テスト用で使ったsql文(oracle) CREATE TABLE EMP (EMPNO NUMBER(4) NOT NULL, ENAME VARCHAR2(10), JOB VARCHAR2(9), MGR NUMBER(4), HIREDATE DATE, SAL NUMBER(7, 2), COMM NUMBER(7, 2), DEPTNO NUMBER(2), CONSTRAINT PK_EMP PRIMARY KEY(EMPNO), CONSTRAINT FK_DEPTNO FOREIGN KEY (DEPTNO) REFERENCES DEPT ); CREATE TABLE DEPT (DEPTNO NUMBER(2), DNAME VARCHAR2(14), LOC VARCHAR2(13)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
What's new in Carton and cpanm at YAPC::Asia 2013
bayashi.jp
search.cpan.org で syntax highlighting - punitan (a.k.a. punytan) のメモ
Amazon.co.jp: Perl CPANモジュールガイド: 冨田尚樹 (著), タナカユカリ (イラスト): 本
Perlモジュールの作り方 | パルカワ！