goでは標準でいろいろなツールが揃っていますが、
npmやbundlerのようなパッケージの依存管理をするツールはありません。

これは、goでは公開されている物は後方互換性を守り、
それを崩す場合は違うインポートパスにするべきだという思想によるものらしいです。

Packages intended for public use should try to maintain backwards compatibility as they evolve. The Go 1 compatibility >guidelines are a good reference here: don’t remove exported names, encourage tagged composite literals, and so on. If different >functionality is required, add a new name instead of changing an old one. If a complete break is required, create a new package >with a new import path. http://golang.org/doc/faq#get_version

そうはいっても、これに従うかどうかはパッケージの開発者の裁量によるため、
自分が管理していないパッケージを利用する場合はどうしても管理が必要になります。

調べたところ、同じような問題に直面している人は多いらしく、いくつかツールがありました。
PackageManagementTools

一応、go公式でもパッケージ管理ソフトを作るという噂を聞きましたが、1.5には入る気配がないので、
とりあえずはこれらの中のどれかを使う必要があります。

そこで、この中で特にスターが多かったgodep、gom、goopについて調べました。

パッケージ管理ツール

この3つに共通する物として、importしている物をリストアップし、ファイルに書き出す機能があるようです。
また、gomとgoopはほぼ同じ機能を提供し、管理用のファイルの形式が違うようです。

godep

https://github.com/tools/godep

こちらはかなりgoの思想に沿った作りをしているツールになります。

このツールはパッケージのインポート情報を保存しますが、バージョンまでは保存しません。
そのため、依存しているパッケージを入れる際は、go getにより最新版をとってきます。

go getでとれないようなリポジトリ用に、プロジェクト内にワークスペースを作ってソースごと保存し、
GOPATHでそこを見るようにしてコマンド実行することもできます。

つまり、常に最新のmasterを使うか、自分の手元で管理するかの二択です。
基本的に全部管理下に置いてある前提の作りっぽいです。

gom/goop

https://github.com/mattn/gom
https://github.com/nitrous-io/goop

gomとgoopはほぼnpmのような使い勝手になるパッケージ管理ツールです。
すなわち、使っているパッケージのバージョンまでも保存します。

依存するパッケージはローカルにフォルダを作ってそこに保存され、
GOPATHにローカルフォルダを含めた状態で実行します。

gomはRakefileのような書式、goopは普通のテキストにちょっと書式が加わったようなものになります。

gomが良さそう

godepはそういう環境やメンテナンスフローから作る必要があり、気軽に導入は難しそうです。
そのため、npmやbundlerに似ているgomやgoopを使った方が楽そうです。

また、gomはRakefileっぽい書式のため、独自?のgoopよりかは使い勝手がよさそうなので、
とりあえずはgomでやろうと思います。

このエントリーをはてなブックマークに追加