先日書きました Carton そのもののインストールについて、それ自身が依存するモジュールが多すぎて大変、という内容の記事でしたが、そのつぶやきを Carton 作者の @miyagawa 氏が拾って下さり、じぶんの不明を正して下さいました。
carton bundle を実行してバンドルされた（モジュールのソースが集められた） vendor ディレクトリの中には、 carton コマンド（スクリプト）が同梱されます！ vendor/bin ディレクトリを覗いてみて下さい。
そのスクリプトは Carton 配布とは違うものではあるのですが、これを使えば別途 Carton 配布を用意して＋ビルドして＋インストールしなくても、バンドルされたすべてのモジュールをインストールすることが出来ます。
方やもう一件、 JPA の @lestrrat 氏からも CPAN のミラーをローカルホスト上に作るのはどうかという旨のコメントを頂きました。いつも使うモジュールを集めておいたり、リポジトリにさまざまな Perl のプロジェクトがあってモジュールの管理を一括したいようなときに、これも知っておくべき手段ではないでしょうか。
ただ先日書いたじぶんの記事では明らかではありませんでしたが、実際の問題として、じぶんはお客さんのところに設置することを想定していました。
そこは外界へのネットワークもなく、かつツールを置く自由に望みが薄い厳しいところです。挙げ句にじぶんは、モジュールのバージョンをインストール順に書き込んだバッチスクリプト作成という not good な方向を突っ走ってしまっていたのですが、そのような塞がった環境では、 Carton の “bundle” による機能がアドバンテージを遺憾なく発揮する事でしょう。
詳細については @miyagawa 氏の記事が上がっていますので、そちらを参照下さればと思います。（もしかしたら迷える私のようなユーザのために書いて下さった？としたらまったく有難い事です。ありがとうございます）
miyagawa/cpan-module-bootstrap - Tatsuhiko Miyagawa’s blog
Carton ──時事ネタ的に言えば、なんておもてなしが行き届いていることでしょう。
少し大袈裟な物言いかもしれませんが、 Carton は Perl の今後を左右しかねない革命的なツールだとじぶんは思っています。尤もその始まりは Ruby の Bundler の存在があってのことでもあったのかも知れませんが、それ同等の環境が整ったことは Perl にとって──一般的には廃れてしまったと認知されていることを否めない Perl にとって、これからもモダンであり実用可能であることの必要条件だったのではないでしょうか。逆に厳しい目で見れば、いままでそのような環境が整っていなかったのは不幸だったと思います。
たとえばある言語をこれから初めて使ってみよう思うデベロッパ・ユーザが、（依存モジュールが多くて）何回も make しないと使えない環境下でそのモジュールが使えるようになるまでのストレスを想像できますでしょうか。本番環境に持って行った時にバージョンが違っていたらどうしようという心配は誰もしていないのでしょうか。 Ruby には Bundler がありました。
でもこれからの Perl には Carton があるのです。