opam_release.md

この文書について

独自研究です。

OPAM でリリース

理論はわかる:

• まずリリースすべきコードを書く
• コードをネットで入手できる所に置く
• opam ファイルを書く
• opam ファイルを opam repo に載せてもらうべく pull request を出す
• Approved!
• 後で何か細かい問題が出て来るので対処

実践が難しい。まだどうやるのが良いのか判っていない。ので考える。

まずリリースすべきコードを書く

これは簡単。コードを書け。

コードをネットで入手できる所に置く

手元にある opam-repository を調べた。全 2279 URLs(パッケージ毎ではなく、バージョン毎に一つ。)

• 956 github
• 309 forge.ocamlcore.org
• 140 bitbucket
• 630 janestreet.com
• それ以外は janestreet 以外の個人やプロジェクトのホームページ

このほとんどが tarball で配布されている。

git repo を指定での配布は非推奨、なぜなら、hogehoge.git などとする git repo での指定は HEAD を指すことになるはずなので、ナマモノという理解。

自分のホームページなどで tar ball を公開している場合は tar ball を作ればよい。おわり。

github なり forge なり bitbucket なりで公開する場合、tag を打てばその revision のファイルが tar ball で手に入るようになっているので、tag を使うことになる。 (forge も tag 打てますよな？) ただし この tag は打ち直しがある事を覚悟すべき。 これ重要。

なぜ tag 打ち直しが必要かというと、 tag 打ってこのリリースはこの revision ですよ？ と一旦固定しても、opam repo に pull request を出してからの自動チェックで通らないことがあるから。 その際にはソースを修正して新しい revision に同じ tag を打ち直すことになる。 Tag をちょんちょんと打ち直すのが良い事かどうかわからないが、リリース時にはどうしても opam repo の pull req での問題露呈が多いし、pull req が通るまでは誰もその tag の付いた revision のコードを opam install しないであろうと思われるので構わない事にしている。

opam ファイルを書く

ソフトウェアを OPAM を通して配布するには次の三つのファイルがまず必要:

• descr: ソフトの説明
• opam: ソフトのインストール方法および依存情報
• url: ソフトの入手先とチェックサム

各ファイルの書き方は本家のドキュメントを読めばよろしいのでここでは説明しない。

URL

url ファイルには tar ball の入手先である URL を書く事になっている。 これはもし github や bitbucket 等を使っていて、レポジトリ名と tag の打ち方が ソフトの名前とバージョンに一致しているのならば、自動生成できるはず。例えば hogehoge のバージョン 1.2.3 なら私の場合は

https://bitbucket.org/camlspotter/hogehoge/get/1.2.3.tar.gz

になる。ので自動化的に作成できるはずだ。なので、しよう。

ただ bitbucket も github も両方使い出すと何か面倒そうだね…

Checksum

url ファイルには更に checksum を書く事になっている。これは tar ball の md5sum。 これは github や bitbucket などで公開している場合、当該 tar ball を入手して md5sum を取らなければならない。これは tar ball の URL から自動化的に作成できるはずだ。 なので、しよう。

私は checksum 抜きの url ファイルから tar ball の URL を得て、その checksum を wget+md5sum で計算して checksum 欄を追加するとういことをしている。

どこに保存するか

最終的に opam ファイルは opam-repository を clone してそこに置いた上で pull req を出して本家に採用してもらうのだけれども、だからと言って opam ファイルを opam-repository のローカルコピーで管理するというのはどうか、と思ってはいる。

各 opam ファイルはソフトウェアに固有のものなのだから、当然そのソフトウェアのレポジトリ にあるべきでは…と思って置いているのだが、これはこれでむずかしい。

• Tag を打つリリースのリビジョンに、それと一致する opam ファイルを置くことがむずかしい。 ソース自体は変っていないのに opam ファイルを変更して push した後 tag を打ち直すというのは どうも変だ。
• opam ファイルメンテナンスを行っているとしばしば複数リリースに対して opam ファイルを 一括して変えたいという欲求がおこる。各リリースごとにそのリリースの opam のみがあるというのは 不便だという経験がある。そこで、 opam-release というブランチを作って今迄のリリースの opam ファイルを集めた物を作って運用してみたが、これはこれで opam ファイル変更の際に このブランチに移る必要があり、便利とはいえなかった。
• opam-repository に置かれた opam ファイルは他人が変更する可能性がある。 opam の記法が微妙に変ったりすると opam-repository 全体の opam ファイルが 記法に併せて変更されることがある。この外側からの変更をソフトウェア本体のレポに反映させる事が むずかしい。 (descr と url が第三者に変更されることは無いと思われる。)