GOを触り始めてしばらくすると依存性が気になってきます。
go get
はnode.jsでいうと全部npm install -g
を使うような感覚がありました。
一人で環境を変えず使う分には問題ないですが、色々と管理を楽にしたいのでパッケージ管理について考えてみます。
※Windows10・Go1.12
パッケージ管理ツールを使う
パッケージ管理ツールは基本的にvendoringツールです。
プロジェクト直下にvenderフォルダを作り、そこにパッケージを入れて参照する。
node.jsでいうとnode_modulesのような感覚だと思います。
GitHubでスター数を見てみます。
- 11,902 – https://github.com/golang/dep
- 7,512 – https://github.com/Masterminds/glide
- 4,444 – https://github.com/kardianos/govendor
- 2,178 – https://github.com/constabulary/gb
- 754 – https://github.com/FiloSottile/gvt
gvtはgbの派生ツール。
また、glideはdepを使うことを推奨していました。
Please consider trying to migrate from Glide to dep
軽く使い方なんかを調べた感じだとdepは他と比べて管理が楽そうです。
特にサンプロコードをコピペして実行などはワンステップで出来そう。
Modulesを使う
Go1.11から試験導入された機能で、それ以前はプロトタイプとしてvgo(Versioned GO)として使われていたようです。
https://github.com/golang/go/wiki/Modules
将来的にはこれによる管理になっていきそうなので、今から始めるならこっちの方がよさそう。
サンプル用のパッケージを使ったサンプルがあったので試してみます。
1 2 3 4 |
> mkdir projects/test/mod > cd projects/test/mod > go mod init narumium/test/mod go: creating new go.mod: module narumium/test/mod |
これでgo.modというファイルが生成されます。
1 2 3 |
module narumium/test/mod go 1.12 |
main.goを書いてgo build
すると自動でダウンロードされます。
1 2 3 4 5 6 7 8 9 10 11 |
package main import ( "fmt" "rsc.io/quote" ) func main() { fmt.Println(quote.Opt()) } |
1 2 3 |
> go build go: downloading golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c go: extracting golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c |
go.modにrequire rsc.io/quote v1.5.2
が追記され、go.sumが生成されます。
ダウンロードされたファイルはどこに行ったかと思うと、%GOPATH%/pkg/mod
内にありました。これでパッケージが環境依存からプロジェクト依存になりそう。
ただモジュール名(今回だとmod)が被ると同じ場所に入れられる。
気にしなくても問題が起きる可能性は低そうではあるが何かしら工夫は必要かも。
go.modがある場所でgo getをするとモジュールとして追加されます。
適当に目のついた使ったことのないパッケージをgetしてみます。
1 2 3 4 |
> go get github.com/muesli/smartcrop go: finding github.com/muesli/smartcrop v0.2.0 go: downloading github.com/muesli/smartcrop v0.2.0 ... |
他フォルダでimportしてもcannot findエラーになります。
mod、sumファイルがごちゃつきますがgo mod tidy
で必要のないものを消せます。
混乱を避けるために従来の方法と使い分けはしない方がよさそう。