• Composer
• Packagist

ざっくりComposer

もう紹介記事は溢れているのでいちいち書く意味を感じないが、とりあえず。

• PHP 5.3 以降で利用可能
• package の依存管理ができる
• Pear を含む複数の種類の package に対応している
• Bundler のように project 単位での package の管理を支援してくれる（project 配下への download と autoloader）
• Composer 独自の package 形式がある
• packagist.org というデフォルトの repository がある（rubygems.org相当）

Composerという言葉の指す範囲

Bundler には Rubygems が package で Bundler が依存解決、という分かりやすい機能の対応関係があるが、Composer の場合は

1. 依存解決を行う Composer
2. Package を作る Composer

と、どっちも Composer が担っている。（Bundler もすでに bundle コマンドで gem が作れてしまうので、実装上は分離していても実際の利用上は分かりにくいのかもしれない。）

Composer のキモは composer.json だが、上に書いたような状態のため、Bundler と Rubygems の関係で言うところの Gemfile も .gemspec もどっちも composer.json に記述するという格好になってしまっている。

正直、この全部入りになってしまう感じが悪い意味で PHP っぽいなと感じる。また、JSON という汎用のフォーマットで書くようにしているのも混乱に拍車を掛けている気がする。パッと見でどっちの目的の composer.json なのか分からない。

Composerでinstallできるもの

上に書いた 2 の Package に相当する部分は間口が広く、

• Pear
• Pear2
• Archive
• VCS

に対応しているので、昔から使っている Pear Package があるのであれば、composer.json で repositories と require に書いてあげるだけでこれを install することができる。例えば Pear の HTTP であれば以下のような感じ。

{
  "repositories": [
    {
      "type": "pear",
      "url": "http://pear.php.net"
    }
  ],
  "require": {
    "pear-pear.php.net/HTTP": "*"
  }
}

これで composer install すると

vendor/pear-pear.php.net/HTTP/

以下に HTTP.php が入る。

当然だが Pear package を入れ始めると例によって Archive_Tar だの Structures_Graph だのも漏れなくついてくる。

PHP 5.3以降で新しく何かを作るならComposerを使うのが楽

基本的には Composer は Pear package などを使う方法を推奨しているわけではなく、packagist.org での composer package の公開を前提にしている。これはちょうど Ruby で言う rubygems.org のようなものだが、Bundler の Gemfile と違い、repositories に packagist.org を記述するという手間は必要なく、決め打ちで実行してくれる。

ただ、packagist.org に公開していなくても自作のコードを composer で install させることはできるので、以下にやったことを整理しておく。

Composer対応

• composer.json を作って repository に入れるだけ
• tag を正しく打っていればバージョンとして使われる（これは VCS 上の tag の話であって composer.json は関係ない）
• 必要最低限は name だけでも ok（もちろん description などはあるべきだけど）
  • name は "vendor name/project name" の書き方で

cf. https://getcomposer.org/doc/04-schema.md#name

Composerでinstall

• install する側の composer.json から composer 対応 repository を追加したうえで require してやる
• 例えば手元の git repository なら url は local の filesystem になる

こんな感じ。

{
  "repositories": [
    {
      "type": "vcs",
      "url":  "/path/to/repository"
    }
  ],
  "require": {
    "vendor/project": "*"
  }
}

Bundler で言うところの

gem 'foo', :path => '/path/to/repository'

に似ているが、require の中で直接 repository の path を書くことはできない。

公開してよいものなら packagist に submit して install する側の composer.json を書き換えてやるとよい。

まっさらからのComposerまとめ

本当にまっさらの状態から自前で用意している依存コードを Composer で管理したい場合、

• Composer 管理対象にしたい repository に composer.json を作って入れる
• Composer で便利機能を install したい repository にも composer.json を置いて vendor 以下に依存コードを入れる

という二つの作業が必要。

過渡期の過ごし方

PHP 5.3 未満のコードにも 5.3 以上のコードにも対応する必要がある場合、当然だが Composer は万能薬にはならない。

この場合は

• 依存されるライブラリなどの側のコードに composer.json を用意しつつ
• PHP 5.3 未満の環境では Pear package や丸ごとコピーなどで対応する

必要がある。

例えば Pear package を利用して 5.1 環境に対応しつつ Composer で 5.3 以降の環境にも対応しようとする場合を考える。

まず Pear package で言うバージョンと Composer で言うバージョンを合わせるか合わせないかの判断が必要になってくる。もちろん合っている方が分かりやすいと思うが、Pear package が見ているバージョン情報はファイル名と package.xml 内のバージョン情報であり、Composer が見ているのはファイル名と VCS の tag である。これまで tag をちゃんと活用していない場合はここが一つネックとなる。

また metadata も別個に保持する必要がある。まぁ初回以降はそれほど大きな手間ではないが、package.xml と composer.json の両方に metadata を用意する必要がある。

やや煩雑だが、この手間を掛けておく価値はあると思う。既存の資産の Composer 対応は思った以上に簡単で、非公開のコード資産でも Composer 管理に移行してしまった方がいろいろ楽ができる。少なくとも VCS とうまく連携できるところはとてもイマドキで、Composer を知ったらいちいち package を作ったり channel サーバ立てたりしていた Pear 時代にはもう戻れないし、Composer が Pear package の install にも対応しているところは migration のためにとてもよい機能だと思う。

これでようやく手で zip や tarball 取って来て配置するという石器時代の手法にオサラバできるようになったんだな…。しみじみ。（自分の管理している範囲のお仕事のコードは自前で Pear package にして管理してたけど。これはこれで packaging と deploy が面倒だなと思っていたのであった。）

なんとなーくいやな予感はしていたのですが。

つか今まで致命的に困ったことはほとんどないのですが、破損チェックなどの失敗メッセージが全然出ないっていう仕様もちょっとすごいなと思った。

※ たまに展開できないものなんかは DLL を利用する他のアーカイバを使ってたかな。

ちょっと勉強するために歌詞のない楽曲が聞きたいなぁと思っていたんだけど、どうも手元のライブラリにはその手のものがない。

つーことで仕方なく日本語で歌詞が入ってて気が散りまくるものを聞いていたんだけど、iTunes の「ソース」のカラムになんか見覚えのある文字がある。SmoothJazz.com ? あー。そうかこれインターネットラジオ聞けるんだった。ということで早速チューニング¹。最近はすっかり podcast だけど、とりあえず流しときたいってときにこの機能はやっぱり便利だなぁ。

おせぇ。

あれだな。なんつーかもう生活に必要なインフラというか、常時接続環境がないってことは、携帯を持ち始めてみんなに認知された頃に携帯を忘れたら不安でたまらなかったような、そんな感覚。つーか自宅サーバに繋がらないと不便で仕方がない。公開できるメモはここに書いていけばいいだけなのでそんなに困らないんだけど、何気なくいろんな使い方をしていたらしい。

そういえば昔、常時接続がほしいばかりにいつも大学に居たなぁ。¹アナログモデムに戻ったときは本当につらかった。今もつらいけど。ADSL が普及してきたのはそのあとなんだけど、実はそんなに遠い過去でもない。時の経つのはなんと早いことか。

でも回線が貧弱だと何かしら成果物ができあがったりするんだよな、これが :-P

なんか高校のときの書道の授業を思い出した。私はこの人の字よりももっと丸い字の方が好きだな。門構えに特徴が出てるんだけど、自分の字は縦の線が外に膨らむように書いている。誰だっけなぁ。昔の中国の有名な人なんだけど。もう忘れちゃった。

小学生の１０人に１人以上が「眠れない」　筑波大学調査 （asahi.com）

次々と課題が与えられ、一つのことを成し遂げた達成感を一緒に味わう時間が足りないんじゃないかと。総合の弊害とは言わないけど、点数化を極度にきらう傾向が一部にあるし、そういう影響もないとは言えないと思う。

もっとシンプルに、一つ一つの「イベント」を大事にしないといけないよね。

http://slashdot.jp/article.pl?sid=03/07/01/1613200

OutLook Express のことではありません。

まー結論としては IE 5 ステってことで。5.5 落としておいたでしょ？ この間。というか HTML なんて非表示が常識ですがね :-P