Goのバイナリへのファイル同梱はstatikで決まり

https://github.com/rakyll/statik

Goのバイナリにファイルを同梱するという誰もが欲しいはずのものがなかなか決定版がなく、go-bindataがメンテを終了し、go-assetsもいまいちメンテが滞っているので、statikを使うことにしました。作者のrakyllさんも実績のある方なので大丈夫でしょう。

statikも少しpull requestの取り込みが滞っていたのですが、試しにpull requestを送ってみたらちゃんと取り込まれたので大丈夫そう。

https://github.com/rakyll/statik/pull/61

元々、ファイル単体を取得する分には問題なかったのですが、ファイルシステムとして走査しようとするとうまく辿れない問題があり、このpull requestで修正しました。ですのでより安心して使えるでしょう。

http.FileSystem インターフェース

こういう、ファイルを同梱するやつは http.FileSystem インターフェースを満たすのがセオリーでstatikもそうなっています。ただ、 http.FileSystem.Open() での単体ファイル取り出しは実装されているものの、ディレクトリ走査のための http.File.ReadDir() が正しく実装されているものが案外少なかったりします。

ちなみに、go-assetsも、正しく実装されていなかったので、一応pull requestを投げてはいます。

https://github.com/jessevdk/go-assets/pull/9

おそらく、ファイル単体を引ければ十分で、ディレクトリを走査して使うケースがあまりないため正しく実装されていないことが多いのでしょう。

statikの良いところ

mTimeを固定する-mオプションがある

mTimeを固定できるため、ビルドのたびに差分がでたりしない

// Code generated... コメントを付けてくれる

https://golang.org/s/generatedcode のルールに則って、自動生成ファイルとして認識してもらえる。

内部データが単なるzipである

データサイズが小さくできるし、ライブラリ側が更新されたとしてもアセットデータの再作成が必要ない。データがシンプルかつ将来に渡って不変で良いというのは、見事な設計。

statik/fs.Walk() が便利

filepath.Walk() と似たようなインターフェースで、 http.FileSystem を走査できる statik/fs.Walk() が定義されておりこれが便利です。僕の場合これが使いたかったので、今回pull requestを送った次第。

http.FileSystem インターフェースが正しく実装されている

今回の修正で正しく実装されました。

ということで

Goでのファイル同梱には statik をメインで使っていこうと思います。決定版になってほしい！