nDiki : PPM リポジトリ

PPM リポジトリ PPM repository

PPM パッケージを集めてある場所。 PPM からリポジトリを指定して、PPM パッケージインストールすることができる。

Web サーバ上に作る方法や、ローカルディレクトリに作る方法などがある。

関連情報

スポンサード リンク

2004年8月21日 (土)

rsync の --copy-unsafe-links

man ページを見ると「コピーツリーの外へのシンボリックリンクのみ実体に置き換え、ツリー内でのリンクはそのまま維持」してくれるようなのだが、どうも期待した動作と違う。 '-l' と一緒に指定すると全てシンボリックリンクのままで、-L と一緒に指定すると全て実体に置き換えられてしまう。

ActivePerl を使用する各プロジェクト毎のPPM リポジトリを、必要とするPPM パッケージについて「ビルド済み/ダウンロード済みPPM パッケージの pool」へシンボリックリンクする事で実現している(というのを今作っている)。 ここでいくつかのプロジェクト分のPPM リポジトリを、必要な実体を無駄なくそろえて export するのに rsync が使えないかと思ったわけだが、現状だと重複して実体がコピーされてしまう。 まあディスク容量はそれほどネックではないから、これでもいいか。

[ 8月21日全て ]

2004年8月22日 (日)

PPM リポジトリ作り

  • プロジェクトで使う依存モジュール(の特定バージョン)を確保しておく
  • PARを使う際にライセンスの確認をしていないモジュールが入らないようにする
    • そのために、依存関係解決のため自動的に芋蔓式にモジュールが入らないように標準の PPM リポジトリを無効化しておく
  • ビルド/ダウンロードした PPM パッケージを集めてプロジェクト専用の PPM リポジトリを用意する

ということで、もりもりパッケージ化作業。 依存モジュールも含めてそれなりの数になるので、チマチマと作業。

[ 8月22日全て ]

2004年9月21日 (火)

ActivePerl 5.8 用 PDL 2.4.1

実は SourceForge.net にあった。 まだ動作確認していないが、問題なければこれで ActivePerl 5.6.1 ともおさらば。

その場合は PPM リポジトリを再構築しなおしであるが。

[ 9月21日全て ]

2004年10月21日 (木)

bundle を作成して Perl モジュールをまとめてインストール

依存モジュールが多くなってきて、開発しているPerl モジュールの実行環境構築が面倒になってきた。

ActivePerl では PPM パッケージ化 + PPM リポジトリで芋蔓式インストールが可能である。 素のPerlだとCPANモジュールでネットワークインストールする事になる。 ここで一個づつインストールしていくのがかったるい。 ということでCPANにあるモジュールのように Bundle::* を作る事にした。

調べてみると簡単。

  • bundle はただのPerl モジュールである。
  • Bundle:: 名前空間に置く。
  • =head1 CONTENTS Podセクションを置き、各行に1つづつ依存モジュールを列挙する。

フォーマットは以下。

 Module_Name [Version_String] [- optional text]

これだけ。Pod に書かせるあたり、とりあえずから始まった感じである。

CPAN上に置あるものはきちんと tarball 化してあるが、ローカルで使う分にはこの bundle Perl モジュールを @INC のどこかに置いておけばよい。

Bundle::MyModule を作ったとすると perl -MCPAN -e shell から 'install Bundle::MyModule' でOK。

CPAN と @INC 上の '.'

カレントディレクトリの下に Bundle/MyModule.pm を置いて

 perl -I . -MCPAN -e shell

として Bundle::MyModule をインストールしようとしたのだがうまくいかない。CPANシェル上の ! コマンドで @INC を出力してみると . が含まれていない。何故? PERL5LIBに設定しても同様。 試行錯誤したところ絶対パスで指定すればOKであった。

CPAN.pm 1.76_01 を読んでみた。

 no lib "."; # we need to run chdir all over and we would get at wrong
             # libraries there

これだ。

[ 10月21日全て ]

2006年7月3日 (月)

自前 PPM リポジトリの管理

Windows Perl アプリケーション用に PPM リポジトリを久しぶりに整理。

自分が使用する PPM パッケージは以下の理由から、以前より基本的に自前でビルド/保存し PPM リポジトリをローカルに作成するようにしている。

  1. 後でオフラインインストールできるようにする。
  2. 「公開リポジトリが無くなった」あるいは「公開リポジトリに欲しいパッケージが無くなった」時に困らないようにする。
  3. 動作確認された組み合わせでの PPM パッケージセットを作成・保持できるようにする。
  4. ライセンス的にクリアなものだけを含むリポジトリを用意する。 (芋蔓式インストールで、ライセンス的にクリアでないパッケージが入ってしまうのを防ぐ)。

手元では以下のように管理

 PPM
  |-- <category>
  |   `-- 8xx
  |       |-- <projects A> [ 公開 / export ]
  |       |   |-- module1.ppd -> (A)
  |       |   |-- module1.tar.gz -> (B)
  |       |   `-- ...
  |       `-- ...
  `-- pool
      |-- module1-x.yy
      |   |-- module1.x.yy.tar.gz
      |   |-- some documents...
      |   `-- build817
      |       |-- module1.ppd (A)
      |       `-- module1.tar.gz (B)
      `-- ...
pool
  • pool ディレクトリに「[モジュール]-[バージョン]」ディレクトリを作成する。同じバージョンでも、異なるバージョンは両方とも別々にキープしておく。
  • その下にソース tarball を置く。
  • ライセンス情報ファイルなども置く (touch Perl-License 等空のファイルを作成しておく)
  • PPM パッケージPPM::Make で作成し、その時に使用した ActivePerlビルド番号別にサブディレクトリを作って .tar.gz と .ppd を置く。
リポジトリ
  • ActivePerlビルド番号別にリポジトリを作成する。基本的には 6xx 系、8xx 系それぞれの中ではバイナリ互換性がある (PAR などは、ビルド番号に1対1でしか互換性がない)。
  • 必要に応じてカテゴリ別サブディレクトリを用意 (アクセス制限の都合などにより)
  • 必要に応じてプロジェクト毎にサブディレクトリを用意 (プロジェクト毎にパッケージセットを作るため)
  • リポジトリディレクトリからは pool 内の .ppd、.tar.gz へシンボリックリンクを張る。欲しいモジュールのバージョン、ビルド番号を選んでリンクする。
公開
  • SambaApache などで、PPM ディレクトリ全部あるいは特定のリポジトリ部分を公開する。
  • 必要なら export して別サーバに置く。rsync や cp の -L オプションでシンボリックリンクを実ファイルに置き換えてアーカイブを作成する。
[ 7月3日全て ]

2006年7月5日 (水)

[ 7月5日全て ]

2006年12月12日 (火)

PAR::Repositoryビルド済み Perl モジュールをネットワーク配信

実行可能ファイル作成としての PAR

PAR といえば Perl スクリプトを実行可能ファイル(Windows なら EXE 形式ファイル)に変換するモジュールとして有名である。

ちなみに実行可能ファイルを作成する部分はは PAR 0.97 より PAR-Packer パッケージに分けられ、PAR 自体はインストールしやすい pure Perl なパッケージになっている。

PAR モジュールアーカイブからのローダとしての PAR

PAR が提供するもう一つの(こちらが本来はメイン?)機能は、プログラムの実行時に必要な Perl モジュールPAR ファイルと呼ばれる Perl モジュールアーカイブファイルからロードする機能である。 XS モジュールなどもコンパイルすることができるどこかの環境で1度ビルドして PAR ファイルにしておけば、同じアーキテクチャのホスト上でそのまま利用することができる。

PAR リポジトリ

ロードしたい PAR ファイルはファイルパスだけではなく URL でも指定することができ、必要な時にオンデマンドでフェッチさせることができる。 これを使えば Perl プログラムの集中管理可能だ。

PAR 0.951 からは PAR リポジトリというコンセプトが追加され、パッケージ毎に作った PAR ファイルをサーバ上(あるいはローカル)のリポジトリに蓄積してオンデマンドでロードできるようになった。

個別に PAR ファイルを指定する従来の方式に比べてかなり便利そうである。 ということで試用してみた。

まずは

あたりをインストールし準備 OK。

1. PAR リポジトリを作成する

最初に PAR-Repository に含まれている parrepo で。

 parrepo create -r /tmp/PAR

PAR リポジトリファイルの中にはデータベースファイルが作成されるが、これは DBM::Deep というアーキテクチャ非依存のものを使っているので、Linux でも Windows でもどちらからでもアクセス可能である (つまり Linux 上でリポジトリをメンテできるということだ)。

2. Perl パッケージを PAR ファイル化する

次に必要な PAR ファイルを作成する。 作成したいパッケージを展開してビルドし、blib ができている状態で PAR::Dist を使ってパッケージ化する。

 perl Makefile.PL
 make
 make test
 perl -MPAR::Dist -e blib_to_par

例えば ActivePerl*1 上で WWW-Mechanize-1.20 を PAR ファイル化すると

 WWW-Mechanize-1.20-MSWin32-x86-multi-thread-5.8.8.par

というファイルが作成される。

普段から ActivePerl で必要なライブラリは基本的に自前で PPM パッケージ化して、動作確認した上で PPM リポジトリに蓄積するようにしているので、合わせて次の手順でパッケージを作ることになる。

 perl Makefile.PL
 nmake
 nmake test
 perl -MPAR::Dist -e blib_to_par
 make_ppm

*1ここでは Windows 上の

3. PAR リポジトリPAR ファイルを登録する

PAR ファイルができたら parrepo でリポジトリに登録する。

 parrepo inject -r /tmp/PAR -f xxx.par

4. PAR リポジトリ上のライブラリを使用してみる

例えば先ほどの WWW::Mechanize がリポジトリに登録されている状態で

 #!/usr/bin/perl
 use PAR { repository => 'file:///tmp/PAR/' };
 use WWW::Mechanize;
 my $mech = WWW::Mechanize->new;
 $mech->get('http://www.example.com');
 print $mech->content;

というスクリプトを書いて実行すると、PAR リポジトリから WWW::Mechanize がロードされて正しく実行される。

ここでリポジトリを Web サーバアップロードして、repository のところに URL を指定するようにすることもできる。 例えばリポジトリを http://www.example.com/PAR/ に配置したとすると

 #!/usr/bin/perl
 use PAR { repository => 'http://www.example.com/PAR/' };
 use WWW::Mechanize;
 my $mech = WWW::Mechanize->new;
 $mech->get('http://www.example.com');
 print $mech->content;

と書き換えることで、インストールしていない WWW::Mechanize を使用できるようになる。

Perl プログラムを実行形式化する

先ほどの Perl スクリプトを get_top_page.pl という名前で保存して pp で実行可能ファイル化する。

 pp -o get_top_page.exe -M PAR::Repository::Client get_top_page.pl

とすれば get_top_page.exe という実行可能ファイルが作成される。 WWW::Mechanize はオンデマンドで http://www.example.com/PAR/ からフェッチされるので、アップデートが必要な場合は新しい PAR ファイルを作成してリポジトリを更新するだけでよい。 EXE ファイルを作成しなおして利用者に配付しなすといった作業も不要だ。

スクリプトもリポジトリにおく

さらには実行するスクリプトをも PAR リポジトリに置いておくことが可能だ。

例えば WWW-Mechanize に含まれている mech-dump をオンデマンドにフェッチして実行する実行形式ファイルは以下のコマンドで作成できる。

 pp -o mech-dump.exe -M PAR::Repository::Client \
   -e "use PAR { repository => 'http://www.example.com/PAR/', \
                 run => 'mech-dump' }"

まとめ

ActivePerl では PPM があるとはいえ、普通のユーザにちょっとしたプログラムを使ってもらうのに「ActivePerlインストールして、PPM パッケージインストールして、……」というのは手間すぎる。

pp で プログラムに必要なものを全てバンドルした実行形式化ファイルにするという方法ももちろんあるのだが、頻繁にアップデートするようなスクリプトの場合には、起動のための部分だけ pp で作成しておいてあとは PAR リポジトリで集中管理するというのもちょっと魅力的である。

[ 12月12日全て ]

2007年2月5日 (月)

ActivePerl 5.8.8.820PPM では ppd/tar.gz を置いただけの PPM リポジトリを使えなくなった

ActivePerl 5.8.8.819 までは .ppd と .tar.gz ファイルを置いたディレクトリを Web サーバで公開しておけば、そのディレクトリの URLPPM リポジトリとして指定して使うことができた。

これが build 820 付属の PPM だとスキャンしてくれなくなった。 リポジトリの URL を指定する際、package.xml を指定しないと駄目らしい。

PPM リポジトリとして必要なファイル群を生成する

PPM リポジトリとして必要なファイル群は PPM-Make に含まれている rep_summary コマンドで生成することができる。

 rep_summary --rep /path/to/ppm/repository

今後はこれで package.xml その他のファイルを生成しておくことにする。

複数の PPM リポジトリ

一方複数の PPM リポジトリの扱いは良くなった。build 819 付属の PPM では、複数のリポジトリにまたがってパッケージの依存解決ができなくなっていて不便だったのだが、build 820 のものでは、以前のバージョンのもののようにまたがれるようになった。

基本的な PPM パッケージ群用と、プロジェクト毎の PPM パッケージ群用の PPM リポジトリを組み合わせて使うときに、依存解決できないと厄介だったのでこれは○。

PATH

build 819 のインストーラでは site\bin に PATH を通してくれないので、site にインストールしたパッケージ付属のコマンドが呼び出せず不便であった(もちろん自分で PATH を通せばよいのだが)。

build 820 のインストーラでは site\bin も PATH にいれてくれるようになった。○。


[ ActivePerl ]

[ 2月5日全て ]

2009年8月25日 (火)

ActivePerl をやめて Strawberry Perl

ActivePerl 5.10.0.1005 + Visual Studio 2005 SP1 上で PAR::Packer を使って実行可能ファイル化したものの、今日別の環境で動かしたら「このアプリケーションの構成が正しくないため、アプリケーションを開始できませんでした」というエラーがでてしまった。

今まで Visual Studio 6.0 で PPM パッケージの作成やら PAR::Packer による実行可能ファイル化をしていたので気がつかなかったのだが、調べてみると Visual Studio 2005 以降だとどうもいろいろ面倒らしい。

ActivePerl + PPM パッケージだと自分で PPM リポジトリを用意しておくことで、開発環境の統一が楽になるという利点があったのだけれどもしばらく一筋縄ではいかなさそうなので、別の Perl ディストリビューションを使ってみることにした。

Windows 上の Perl としてしばらく使ってみることにしたのは Strawberry Perl。現在のバージョンは 5.10.0.6。 以前にもちょっと入れてみたことはあったけれども、きちんと使ってみるのは初めて。

MinGW や dmake が同梱されており、CPAN.pm を使って UNIX 上と近い感覚で Perl モジュールインストールができる。 PAR::Packer を使って実行可能ファイル化した Perl スクリプトも実行できることを確認。

しばらく乗り替えてみることにする。

[ 8月25日全て ]

2011年10月14日 (金)

YAPC::Asia Tokyo 2011 1日目

@941 → @obra → @miyagawa → @naoya_ito → @ockeghem → @fujiwara → @zigorou → @ikasam_a → @overlast → @lestrrat (LT)

今年は講堂に YAPC タイムラインを写すスクリーンが公式に用意されたため、発表者が Growl 起動してなくても Tweet をシェアできるようになった。自分の端末に目を落とさなくても良いのでいいね。機材や場所の制約があって難しいのだろうけど、他の会場にもあると嬉しいな。

トーク

Perl 5.16 and beyond: Jesse Vincent (@obra)

Perl 5 が互換性を大切にしていく。コアを小さくしていく。

成熟期に入っているので、膨大な資産が継続して使い続けられることはとても重要な要素。

Carton: CPAN dependencies manager: Tatsuhiko Miyagawa

CPAN モジュールインストール状態の記録と再構築を容易にする Carton の紹介。

6年前とかにこういうの欲しかった。 特にパッケージ製品とか作っていると、動作確認のとれた依存ライブラリ一式の保存と管理が大切。自前で tarball 保存(+ PPM パッケージ作成と PPM リポジトリの構築)をしていた日々が思い出される。

SmartPhone development guide with Node/CoffeeScript and HTML5 technologies, for Perl programmers: Naoya Ito

JavaScript のお話。

Webアプリでパスワード保護はどこまでやればいいか: 徳丸浩

まだまだソルト健在。レインボーテーブルは発想が賢い。

Perlで構築された中規模サイトのDC引っ越し記録: FUJIWARA Shunichiro

稼働中のサービスのサーバ移転に関する顛末。

Mobage オープンプラットフォームの事件簿: Toru Yamaguchi

MySQL なお話。

他言語から見たPerlのテスト: Masaki Nakagawa

テストフレームワーク・テスト用モジュールいろいろあるね。 浅く広く紹介。

Apporoで類似文字列検索: Toshinori Satou

前半は技術開発プロセスに関する雑感、後半は類似文字列検索 Apporo の紹介。

@overlast 氏とは懇親会で話をさせていただいて「うーん、やはり悪徳業者投稿コンテンツの検出はヒューリスティックにやっていくしかないのかな」という点で意見が一致。

LT

いろいろ。

懇親会

思ったより食えました。

前職で一緒に研究開発をしていた @k12u 氏と再会できて嬉しかった。かわらず元気そうで何より。

Perlっ!」って話は最初の2本で、後はその他の技術もろもろ。アリだけど個人的にはもっと Perl の話も聞きたーい。

[ 10月14日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.04983s / load averages: 0.27, 0.50, 0.49
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker