初めてPackagist.orgに登録してみた
あるいは久しぶりに書くけど Kanazawa.rb meetup 32 に参加してきた話。
今回は「意識高いもくもく会」。初参加の方が3名もいて、暖かくなってきたのもあって、新しい風を感じたりしていた。
今日の自分の課題は packagist への package 登録。
packagist.orgとは
まず Composer ってのがある。これについては以前まとめたのがあるので、もしまだよく分かっていないということであれば参照のこと。要は Ruby の Bundler のようなもの。
今さらComposer - あーありがち(2014-07-02)
で、デフォルトのリポジトリが packagist.org で、ここに自作のパッケージを登録しようと思ったのが始まり。
composer, packagist って利用方法の記事は多いけど、作る系の情報って全然ないなと気づいたので、実際にやってみた。
composer package という tarball のようなものは存在しない
meetup が始まる前にこの辺は調べがついていて、なんとなくそうなんじゃないかなーと思っていたけど、composer って
- 依存性解決を行うけど
- アーカイブは導入しない
という考え方になっている。
じゃあ packagist.org って何ってことになるんだけど、これは単に公開されている VCS とヒモ付けを行って、composer の search や install を助けてくれるだけのものとなっている。
デメリット
実際の install は単に github から clone してるだけだったりする。ということは、deploy 時に composer install を行おうと思ったら例えば github.com も packagist.org も両方生きていなければいけないということになる。これは deploy の信頼性を考える場合にデメリットにもなり得る。
repositories という記述を追加することで mirror を参照させることもできるので対策は打てるけど、Bundler のようにまとめて source を追加、切り替えられるわけではないので、マジメに考えるとちょっと面倒くさそうではある。
（例えば Sqale.jp という PaaS は gem を mirror してそっちを見にいくようにしている。Ruby アプリが増えれば増えるほど bundle install は帯域的につらくなりそうなので、これは正しいアプローチだと思う。こういうのは Gemfile なら簡単だけど composer.json だと大変そう。なんか方法あるのかな。）
メリット
この方式のメリットは、VCS への commit, push とパッケージの登録作業を別々に行う必要がないということ。バージョンは単に VCS 上のタグで表現される。
ということは package 登録作業者を packagist.org 上で collaborator 登録するということも必要なくなる。例えば github の organization で開発を行っているのであれば、そこに push できる人は全員 package の更新にも参加していることになるわけだ。そういう意味では管理はとても楽。
実際の登録、というか
前置きが長くなってしまったが、要は登録作業なんてものは存在しないので、やることは本当に少ない。
今回自分がやったのは
- packagist.org にアカウント作成
- packagist.org 上で github.com の repository 情報を追加
- github.com の webhook に packagist.org の credential を追加
以上である。実際にやった結果は
wtnabe/ga-shikomi-php - Packagist
で、リポジトリは
えーとこれの説明はしたっけ。してないよね。まぁいいや。時間がないのでまた今度。
おまけ : minimum-stability
これは単に依存の記述次第なんだけど、例えば
の場合、しばらく x.x.x-dev みたいなのが並んでいるので、自分はこれが正式版なのかなと思っていたけど、これは違うのね。あくまで dev バージョンの記述。
で、これに
require
で依存しちゃうと、stability の問題で通常は install できなくなってしまう。この問題については以下のブログ記事が詳しい。
Composerがパッケージのstabilityを解決するしくみ - オープンソースこねこね
require-dev
での依存ならオッケーだけど、require は stable が基本なので、そのままだと install できなくなってしまう。これを書いている時点では上の ga-shikomi-php も
"minimum-stability": "dev"
を追加しないと動かない。分かってしまえば「あぁ、そういや Pear も beta が install できなかったな」と思い出すこともできるんだけど。
ただ問題は
no matching package found.
とか、エラーメッセージが依存しているバージョンの stability の問題という意味に取れない場合があること。
ということで注意事項として改めてメモしておく。
おまけその2
The Twelve-Factor App を参照しつつ、開発者のレベルを上げていきましょうという発表を行った。まだ方法練ってないけど 12-factor を参考にしつつ具体的な改善を考えたりする勉強会というか Kanazawa.rb 内のサークルみたいなものを始めようと思っている。
おまけその3
この日時点で CF 作成実績 489 個、もうすぐ Mind Controller Silver になり、L10 のメダル要件が揃うところまできた。
ということで packagist 登録もできて Ingress もできてビールがうまかったぜ！