トップ «前の日記(2015-04-05) 最新 次の日記(2015-09-01)» 編集

2015-04-25 [長年日記]

_ 初めて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

で、リポジトリは

wtnabe/ga-shikomi-php

えーとこれの説明はしたっけ。してないよね。まぁいいや。時間がないのでまた今度。

おまけ : minimum-stability

これは単に依存の記述次第なんだけど、例えば

symfony/console - Packagist

の場合、しばらく 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 もできてビールがうまかったぜ!

Tags: Composer PHP