List of Versioning [text.Baldanders.info]

Go モジュールのバージョン管理

2019-05-04T04:08:19+00:00

今回の長期休暇を利用して今まで公開したツールやパッケージ類をチューニングしているのだが， Go 1.11 以降から実装されているモジュール対応モード（module-aware mode）のバージョン管理の挙動が（ドキュメントを読んだだけでは）ピンとこなかったので，この際いろいろと試してみることにした。

試して壊して試して壊して… を繰り返した成果が今回の記事である¹。まとめは最後に書いておくのであしからず。

みんな大好き Hello World

まずは以下の簡単なパッケージを作ってみる。

hello/
├── go.mod
└── hello.go

go.mod ファイルの内容は以下の通り。今回の記事では先頭行の module ディレクティブに注目する。 module ディレクティブはパッケージのモジュール・パスを定義するもので，このモジュールパスとバージョンのセットがモジュールの IDentity となる。

module github.com/spiegel-im-spiegel/hello

go 1.12

hello.go ファイルの内容は以下の通り。

package hello

import "fmt"

func Hello() {
	fmt.Println("Hello World")
}

このパッケージをリポジトリに push してバージョンタグ v1.0.0 を付ける。

パッケージを使う側のコードも書いておこう。

package main

import "github.com/spiegel-im-spiegel/hello"

func main() {
	hello.Hello()
}

これを実行すると以下のようになる。

$ go run main.go 
go: finding github.com/spiegel-im-spiegel/hello v1.0.0
go: downloading github.com/spiegel-im-spiegel/hello v1.0.0
go: extracting github.com/spiegel-im-spiegel/hello v1.0.0
Hello World

このとき，パッケージを使う側の go.mod は以下のようになっているはずである（モジュール名は適当）。

module work

go 1.12

require github.com/spiegel-im-spiegel/hello v1.0.0

前準備はこれで OK

パッケージのバージョンを v2 にアップグレードする

ではこの hello パッケージを少し弄ってみよう。まずは安直に hello.go 関数を以下のように変更する。

package hello

import "fmt"

func Hello(name string) {
	fmt.Println("Hello", name, "by v2")
}

Hello() 関数の後方互換性が失われたのでメジャーバージョンを上げることにしよう。このコードを push してバージョンタグ v2.0.0 を付ける。

この新しいパッケージで使う側のコードを修正してみる。

package main

import "github.com/spiegel-im-spiegel/hello"

func main() {
	hello.Hello("Golang")
}

go.mod ファイルも直さないとね。

module work

go 1.12

require github.com/spiegel-im-spiegel/hello v2.0.0

これを実行すると以下のようになる。

$ go run main.go 
go: finding github.com/spiegel-im-spiegel/hello v2.0.0
go: downloading github.com/spiegel-im-spiegel/hello v0.0.0-20190503134808-f31e6a72de0f
go: extracting github.com/spiegel-im-spiegel/hello v0.0.0-20190503134808-f31e6a72de0f
Hello Golang by v2

ありゃりゃ。 v2.0.0 のモジュールを見つけたまではよかったが，ダウンロード時にバージョンタグを認識していない？

ここで思い出したのが Semantic Versioning のルールである。

via Semantic Import Versioning

ひょっとして v2 ディレクトリを切ったらいいのか？試してみよう²。

v2 ディレクトリによる分離

先ほどのコミットはなかったことにして， hello パッケージの構成を以下のように変える。

hello/
├── go.mod
├── hello.go
└── v2/
    └── hello.go

hello.go が v1 のコードで v2/hello.go が v2 のコードである。

このパッケージを使う側のコードも以下のように変える。

package main

import "github.com/spiegel-im-spiegel/hello/v2"

func main() {
	hello.Hello("Golang")
}

go.mod はこんな感じ？

module work

go 1.12

require github.com/spiegel-im-spiegel/hello/v2 v2.0.0

これで実行してみよう。

$ go run main.go 
go: finding github.com/spiegel-im-spiegel/hello/v2 v2.0.0
go: github.com/spiegel-im-spiegel/hello/v2@v2.0.0: go.mod has non-.../v2 module path "github.com/spiegel-im-spiegel/hello" (and .../v2/go.mod does not exist) at revision v2.0.0
go: error loading module requirements

ええつと？あぁ，そうか。パッケージ側のv2/ ディレクトリにも go.mod ファイルがいるのか。

んじゃあ，以下の内容の v2/go.mod ファイルを追加して v2.0.1 タグを付ける。

module github.com/spiegel-im-spiegel/hello/v2

go 1.12

これでパッケージの構成は以下のようになった。

hello/
├── go.mod
├── hello.go
└── v2/
    ├── go.mod
    └── hello.go

では，このパッケージを使って先ほどのコードを動かしてみよう。

$ go run main.go 
go: finding github.com/spiegel-im-spiegel/hello/v2 v2.0.1
go: downloading github.com/spiegel-im-spiegel/hello/v2 v2.0.1
go: extracting github.com/spiegel-im-spiegel/hello/v2 v2.0.1
Hello Golang by v2

ようやく動いたよ… orz

インポートパスをリダイレクトしたかったのだが…

パッケージ側の構成はこれでいいとして，パッケージをインポートする側は

import "github.com/spiegel-im-spiegel/hello"

で v2 のコードを動かしたいよね。というわけで go.mod を以下のように書いてみる。

module work

go 1.12

require github.com/spiegel-im-spiegel/hello/v2 v2.0.1

replace github.com/spiegel-im-spiegel/hello v2.0.1 => github.com/spiegel-im-spiegel/hello/v2 v2.0.1

これで動かすとどうなるか。

$ go run main.go 
go: finding github.com/spiegel-im-spiegel/hello v2.0.1
go: finding github.com/spiegel-im-spiegel/hello/v2 v2.0.1
go: downloading github.com/spiegel-im-spiegel/hello/v2 v2.0.1
go: extracting github.com/spiegel-im-spiegel/hello/v2 v2.0.1
Hello Golang by v2

おっ，うまくいったっぽい？でも go.mod ファイルを見てみると

module work

go 1.12

require (
	github.com/spiegel-im-spiegel/hello v0.0.0-20190503144136-a8f02ef988d2 // indirect
	github.com/spiegel-im-spiegel/hello/v2 v2.0.1
)

replace github.com/spiegel-im-spiegel/hello v0.0.0-20190503144136-a8f02ef988d2 => github.com/spiegel-im-spiegel/hello/v2 v2.0.1

てな感じに書き換えられてしまった。ふむむむむ？

どうもパッケージ内のディレクトリ名とバージョンタグを暗黙的に関連付けているようだ。なので v2.x タグは hello/v2/ ディレクトリに関連付けられてしまう。

たとえば同じリビジョンに v1.0.1 タグを付ければ

という感じで hello/ ディレクトリにもバージョンタグが割り当てられる。もっともそれで

module work

go 1.12

require (
	github.com/spiegel-im-spiegel/hello v1.0.1
	github.com/spiegel-im-spiegel/hello/v2 v2.0.1
)

replace github.com/spiegel-im-spiegel/hello v1.0.1 => github.com/spiegel-im-spiegel/hello/v2 v2.0.1

としたところで更なる混乱を招くだけだけどね。

“Malformed Module Path”

ならば，旧い v1 の方を別ディレクトリに移動すればいんじゃね？って思うよね。私は思った。

で，パッケージ側を

hello/
├── go.mod
├── hello.go
└── v1/
    ├── go.mod
    └── hello.go

という構成にし，呼び出す側の go.mod ファイルを

module work

go 1.12

require github.com/spiegel-im-spiegel/hello v1.0.1

replace github.com/spiegel-im-spiegel/hello v1.0.1 => github.com/spiegel-im-spiegel/hello/v1 v1.0.1

とかやってみたんだけど

invalid module version github.com/spiegel-im-spiegel/hello/v1: malformed module path: github.com/spiegel-im-spiegel/hello/v1

とか言われたですよ。いや “malformed module path” て orz

結局 モジュール対応モード下でメジャー・バージョンを上げたならモジュール・パスも変えるしかない ということらしい。

v2 ブランチを切って運用する

とはいえバージョンごとに物理的にディレクトリを切って運用するというのは今時ありえないダサさである。そこで物理的にディレクトリを切るのではなくリポジトリ上でブランチを切って運用することを考える。

パッケージのディレクトリ構成は v1 と同じ。

hello/
├── go.mod
└── hello.go

これに対して v2 ブランチを切り， v2 ブランチ上で go.mod を以下のように変更する。

module github.com/spiegel-im-spiegel/hello2/v2

go 1.12

モジュールのパスと物理パスが異なっている が気にしないで先に進む。 hello.go を

package hello

import "fmt"

func Hello(name string) {
	fmt.Println("Hello", name, "by v2")
}

として go.mod とともに v2 ブランチに commit & push し，バージョンタグ v2.0.0 を付与する。

パッケージを使用する側のコードは以下の通り。

package main

import "github.com/spiegel-im-spiegel/hello/v2"

func main() {
	hello2.Hello("Golang")
}

これを実行すると

$ go run main.go 
go: finding github.com/spiegel-im-spiegel/hello/v2 v2.0.0
go: downloading github.com/spiegel-im-spiegel/hello/v2 v2.0.0
go: extracting github.com/spiegel-im-spiegel/hello/v2 v2.0.0
Hello Golang by v2

という感じでうまく動いたようだ。 go.mod の内容も

module work

go 1.12

require github.com/spiegel-im-spiegel/hello/v2 v2.0.0 // indirect

となっていた。よーし，うむうむ，よーし。

ブランチとモジュール・パスの関係は以下のような感じだろうか。

まとめると…

v1 以降，メジャーバージョンを上げる度にモジュール・パスを変更して管理を分ける
- v2.x なら path/to/module/v2 などとする。最後の v2 がポイント
- パスの最後がバージョン番号（v2 など）になっていれば，暗黙的にバージョンタグが対応する
モジュール・パスを変更するには go.mod ファイルの module ディレクティブを変更する
- 物理的にディレクトリを切るのであれば go.mod ファイルも含める
- バージョンごとにブランチを切って管理するのであれば，各ブランチの go.mod ファイルで指定するモジュール・パスに注意する
パッケージを利用する側はリポジトリの物理パスとモジュール・パスが異なる場合があるため go.mod ファイルに記述されているモジュール・パスを確認する
同一パッケージの異なるメジャー・バージョンのモジュール・パスを replace で繋がないこと。更に分かりにくくなるか指定によってはエラーになる

といったところだろうか。

バージョンごとにパッケージのパスを分けるため gopkg.in といったサービスが使われることがあるが，リポジトリの物理パスとモジュール・パスが異なる場合は注意が必要である。うまくパッケージをダウンロードできない場合は go.mod ファイル内に

replace gopkg.in/russross/blackfriday.v2 v2.0.1 => github.com/russross/blackfriday/v2 v2.0.1

といった記述が必要になるかもしれない（というかそれが元々の replace ディレクティブの機能）。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

著者のひとりは（あの「バイブル」とも呼ばれる）通称 “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

実際にはこの記事で書いた量の三倍くらいは試して壊して… を繰り返している。 ↩︎
ちなみに v0 から v1 へのアップグレード時にはこのようなことは起きない。一般的に v0 系はベータ版と認識されていて後方互換性については煩くない。 Go 言語のモジュール対応モードでもチェックが入らないようだ。言い方を変えると v1 以降は（Semantic Versioning に従うなら）後方互換性についてちゃんと考えないといけないってこともであるのだが。バージョン設計と運用は意外と難しい？ ↩︎

モジュール対応モードへの移行を検討する

2018-10-22T06:55:11+00:00

Go 言語コンパイラのバージョン 1.11から搭載された「モジュール対応モード」だが，少し試してみてそれなりに使えそうなので，この記事である程度まとめておくことにした。これからも何かあればこの記事に加筆・修正していく予定である。

なお，モジュール対応モードは 1.11 時点で preliminary support に過ぎないため，以降のバージョンで大きな変更が行われるかもしれない。したがってこの記事はバージョン 1.12 以降で大幅に書き替える可能性がる。

【2021-02-25 追記】 なお，このブログで書き散らした内容をまとめる形で以下の Zenn 記事を書いた。こちらも併せてどうぞ。

Go のモジュール管理【バージョン 1.16 改訂版】

用語の整理

まず最初に用語の定義をしておく。

GOPATH モードとモジュール対応モード

バージョン 1.11 以降からは Go 言語コンパイラは以下の2つのモードのどちらかで動作する¹。

GOPATH モード (GOPATH mode) : バージョン 1.10 までの動作モード。標準ライブラリを除く全てのパッケージの管理とビルドを $GOPATH 以下のディレクトリで行う。パッケージの管理はリポジトリの最新リビジョンのみが対象となる
モジュール対応モード (module-aware mode) : 標準ライブラリを除く全てのパッケージをモジュールとして管理する。モジュールの管理とビルドは任意のディレクトリで可能で，モジュールはリポジトリのバージョンタグまたはリビジョン毎に管理される

「モジュール」とは

モジュール対応モードでは，標準ライブラリを除くパッケージを「モジュール（module）」として管理する。パッケージが git 等のバージョン管理ツールで管理されている場合はバージョン毎に異なるモジュールと見なされる。つまりモジュールの実体は「パッケージ＋バージョン」ということになる。

ただしコード上ではパッケージとモジュールの間に区別はなく，したがってソースコードを書き換える必要はない。モジュールはソースコードではなく go.mod ファイルで管理される。

環境変数 $GO111MODULE

バージョン 1.11 では2つのモードの切り替えのために環境変数 $GO111MODULE でモードを指定する。環境変数 $GO111MODULE は以下の値をとり得る。

値	内容
`on`	常にモジュール対応モードで動作する
`off`	常に GOPATH モードで動作する
`auto`	`$GOPATH` 以下のディレクトリにあるパッケージは GOPATH モードで，それ以外はモジュール対応モードで動作する

バージョン 1.11 では，環境変数 $GO111MODULE の既定値には auto が設定されている。独自の開発環境や IDE を使用しているためモジュール対応モードへの移行が難しい場合には $GO111MODULE を off にするとよいだろう。

【追記 2019-03-24】 Go 1.12 でも引き続き auto が規定値になっている。なお 1.13 からはモジュール対応モードが既定になるらしい。そうなれば環境変数 $GO111MODULE はお役御免になるかな。

【追記 2019-12-20】結局 Go 1.13 でも引き続き auto が規定値になっている。ただし go.mod ファイルでモジュールとして定義されているパッケージについては $GOPATH 以下に配置されていてもジュール対応モードで動作する（GO111MODULE が on または auto の場合）。

モジュール対応モード移行への準備

本格的にモジュール対応モードへ移行する前に，以下の準備を行う。

Semantic Versioning によるバージョン管理

モジュールのバージョンははリポジトリのリビジョン番号またはバージョンタグによって管理されるが，バージョンタグに関しては Semantic Versioning のルールに則ってバージョン番号を設定することが推奨されている²。

via Semantic Import Versioning

このように後方互換性のない変更がある場合にはメジャーバージョンを，後方互換性が担保された変更や追加についてはマイナーバージョンを，不具合や脆弱性の修正については第3位のパッチバージョンを上げるようにする。またメジャーバージョンを上げる際には，図のようにディレクトリを分離するか，旧バージョン用にブランチを切るのがよいだろう³。

バージョンタグによってバージョン管理を行うのであればきちんとルールを決めて管理する必要がある。リポジトリ管理に Git を使うのであれば Git Flow や GitHub Flow などが参考になるかも知れない。

GitHub 等の SaaS ではバージョンタグを使ったリリース管理がやりやすいように構成されているし，上手く使ってほしい。

なにはさておき go.mod ファイルを作成する

モジュール対応モードでは go.mod ファイルでモジュール管理を行う。そういうわけで，なにはさておき go.mod ファイルを作ってしまおう。

適当なディレクトリで以下のコマンドを実行する。

$ go mod init hello
go: creating new go.mod: module hello

ここで hello というのがモジュール名（厳密にはモジュール・パス）になる。モジュール名は Go 言語の名前として使えるものであれば何でもいいが，パッケージ名（厳密にはパッケージ・パス）と合わせておくと面倒がない。たとえば GitHub に github.com/my/package というパッケージを公開するのであれば，モジュール名も

$ go mod init github.com/my/package
go: creating new go.mod: module github.com/my/package

としておくのがいいだろう。

コンパイル時に参照する go.mod ファイルがどこにあるかは環境変数 $GOMOD を見ればよい。

$ go env GOMOD
/home/username/workspace/gpgpdump/go.mod

カレント・ディレクトリに go.mod ファイルがない場合は親ディレクトリに遡って探すようだ。まぁ，サブパッケージはディレクトリで階層化されているから当然なんだけど。

なお，カレント・ディレクトリにも親ディレクトリを遡っても go.mod ファイルがない場合は /dev/null （Windows 環境では NUL）を空の go.mod ファイルと見なして処理を継続する⁴。

$ go env GOMOD
/dev/null

dep からの移行

既存のパッケージに go.mod ファイルを追加する場合も同様の操作でよい。なお dep を使ってパッケージ管理を行っている場合は Gopkg.lock ファイルを読んで go.mod ファイルに組み込んでくれる。

$ go mod init github.com/spiegel-im-spiegel/gpgpdump
go: creating new go.mod: module github.com/spiegel-im-spiegel/gpgpdump
go: copying requirements from Gopkg.lock

なんて便利！

go.mod の内容

ここで作成した go.mod ファイルの中身を見てみよう。

たとえば github.com/spiegel-im-spiegel/gpgpdump パッケージの go.mod ファイルの内容は以下の通り。

module github.com/spiegel-im-spiegel/gpgpdump

go 1.12

require (
	github.com/BurntSushi/toml v0.3.1
	github.com/inconshreveable/mousetrap v1.0.0 // indirect
	github.com/spf13/cobra v0.0.3
	github.com/spf13/pflag v1.0.3 // indirect
	github.com/spiegel-im-spiegel/gocli v0.9.4
	golang.org/x/crypto v0.0.0-20190320223903-b7391e95e576
	golang.org/x/xerrors v0.0.0-20190315151331-d61658bd2e18
)

module や require は命令（directive）と呼ばれるもので，これらの命令を使ってモジュールの管理を行う。 go.mod ファイルの記述で使える命令は以下の通り。

命令	記述例
`module`	`module my/thing`
`go`	`1.12`
`require`	`require other/thing v1.0.2`
`exclude`	`exclude old/thing v1.2.3`
`replace`	`replace bad/thing v1.4.5 => good/thing v1.4.5`

module はカレント以下のディレクトリにあるパッケージに対するモジュール名を定義する。前述したようにモジュール名（モジュール・パス）はパッケージ名（パッケージ・パス）と合わせておくほうが面倒がない。

go は対応する Go 言語のバージョンを指定する。マイナーバージョンまで指定すれば OK だが，指定しなくても動作に支障はない。おそらく将来的に go.mod ファイルの後方互換性が確保できなくなった場合の保険だろう。

require はカレントのモジュールが要求するモジュール名とバージョンを指定する。つまり require で指定したモジュールが，カレント・モジュールが依存する外部モジュールとなるわけだ。

exclude は管理から除外するモジュールを指定する。不具合等で特定のバージョンのモジュールを使いたくないときなどに使える。

replace はモジュール名の置き換えである。パッケージ・パスのリダイレクトなどで名前と実体が一致しないときなどに使える。たとえば以下のような感じ⁵。

module md2html

require gopkg.in/russross/blackfriday.v2 latest
replace gopkg.in/russross/blackfriday.v2 latest => github.com/russross/blackfriday/v2 latest

この件については後ほど詳しく説明する。

モジュール対応モードで使う主なコマンド

それではモジュール対応モードで色々と操作してみよう。

go build や go test や go run のようなコマンドは，モジュール対応モードでも変わりなく使える。ビルド時に必要なモジュールは自動的にダウンロードされるため，事前に go get -u ./... みたいなことはしなくていいようだ。

$ go run hello.go
go: finding rsc.io/quote v1.5.2
go: downloading rsc.io/quote v1.5.2
go: finding rsc.io/sampler v1.3.0
go: finding golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c
go: downloading rsc.io/sampler v1.3.0
go: downloading golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c
Hello, world.

なお go get の挙動については後ほど詳しく紹介する。

go list コマンドは -m オプションを付けることでモジュールに対応した。

$ go list -m -u all
go: finding github.com/pkg/errors v0.8.0
go: finding github.com/spf13/pflag v1.0.2
go: finding github.com/spf13/cobra v0.0.3
go: finding github.com/BurntSushi/toml v0.3.0
go: finding github.com/spiegel-im-spiegel/gocli v0.8.0
go: finding github.com/inconshreveable/mousetrap v1.0.0
go: finding golang.org/x/crypto v0.0.0-20180816225734-aabede6cba87
go: finding golang.org/x/crypto latest
go: finding github.com/BurntSushi/toml v0.3.1
github.com/spiegel-im-spiegel/gpgpdump
github.com/BurntSushi/toml v0.3.0 [v0.3.1]
github.com/inconshreveable/mousetrap v1.0.0
github.com/pkg/errors v0.8.0
github.com/spf13/cobra v0.0.3
github.com/spf13/pflag v1.0.2
github.com/spiegel-im-spiegel/gocli v0.8.0
golang.org/x/crypto v0.0.0-20180816225734-aabede6cba87 [v0.0.0-20180910181607-0e37d006457b]

実行結果から github.com/BurntSushi/toml と golang.org/x/crypto には新しいバージョンがあることが分かる。この情報を基に go.mod を調整していけばいいだろう。

新しく追加されたモジュール対応モード用のコマンド go mod はこんな感じ。

$ go help mod
Go mod provides access to operations on modules.

Note that support for modules is built into all the go commands,
not just 'go mod'. For example, day-to-day adding, removing, upgrading,
and downgrading of dependencies should be done using 'go get'.
See 'go help modules' for an overview of module functionality.

Usage:

        go mod <command> [arguments]

The commands are:

        download    download modules to local cache
        edit        edit go.mod from tools or scripts
        graph       print module requirement graph
        init        initialize new module in current directory
        tidy        add missing and remove unused modules
        vendor      make vendored copy of dependencies
        verify      verify dependencies have expected content
        why         explain why packages or modules are needed

Use "go help mod <command>" for more information about a command.

go mod init は既に紹介したとおり。他によく使うものといえば go mod download と go mod graph だろうか。

go mod download は go get -u ./... の代わりに使える。 go mod graph はモジュール間の依存関係を調べるときに使えるだろう。

“go mod graph” を視覚化する

go mod edit は go.mod ファイルを編集するためのコマンドだが手で書いたほうが早い（笑）まぁ何らかのバッチ処理で使える感じだろうか。

モジュール間の依存関係の構造化

以下のコードに対して

package main

import (
    "fmt"

    "rsc.io/quote"
)

func main() {
    fmt.Println(quote.Hello())
}

go.mod ファイルの内容が以下の通りだとする。

module hello

require rsc.io/quote v1.5.2

これに対して go mod graph コマンドを実行すると以下のようになる。

$ go mod graph
hello rsc.io/quote@v1.5.2
rsc.io/quote@v1.5.2 rsc.io/sampler@v1.3.0
rsc.io/sampler@v1.3.0 golang.org/x/text@v0.0.0-20170915032832-14c0d48ead0c

これを図式化すると以下のようになるだろう。

graph TD hello["hello"] quote["rsc.io/quote@v1.5.2"] sampler["rsc.io/sampler@v1.3.0"] text["golang.org/x/text@v0.0.0-20170915032832-14c0d48ead0c"] hello--"hello/go.mod"-->quote quote--"rsc.io/quote@v1.5.2/go.mod"-->sampler sampler--"rsc.io/sampler@v1.3.0/go.mod"-->text

hello モジュールは go.mod より rsc.io/quote@v1.5.2 モジュールを参照している。 rsc.io/quote@v1.5.2 モジュールは自身の go.mod より rsc.io/sampler@v1.3.0 モジュールを参照している。同じように rsc.io/sampler@v1.3.0 モジュールからも依存モジュールを参照しているわけだ。

hello/go.mod には rsc.io/sampler@v1.3.0 等のモジュールについての記述はないが， rsc.io/quote@v1.5.2/go.mod や rsc.io/sampler@v1.3.0/go.mod の記述から依存関係を階層的に取得することができる。

このようにモジュールごとに go.mod ファイルを記述していくことで依存関係の構造化を実現できる。

research!rsc: Minimal Version Selection (Go & Versioning, Part 4)

だからみんな。なにはさておき go.mod ファイルを作成するんだ！

モジュールのキャッシュとビルド・キャッシュ

パッケージのコンパイル結果は環境変数 $GOCACHE の示すディレクトリにキャッシュされる。モジュール対応モードではモジュール単位でキャッシュされるようだ。したがって $GOCACHE の値は off にせず，正しいディレクトリを指定する必要がある。

Go 1.12 からは $GOCACHE を off にできなくなった。 off をセットするとビルドに失敗するようだ。

The build cache is now required as a step toward eliminating $GOPATH/pkg. Setting the environment variable GOCACHE=off will cause go commands that write to the cache to fail.

via Go 1.12 Release Notes - The Go Programming Language

$GOCACHE の値は go env コマンドで確認できる⁶。

$ go env GOCACHE

ビルド・キャッシュをクリアするには以下のコマンドを実行する。

$ go clean -cache

ダウンロードしたモジュールのソースコードは今のところ $GOPATH/pkg/mod 以下に格納される。モジュールのソースコードを含めて全てのキャッシュをクリアするには以下のコマンドを実行する。

$ go clean -modcache

Go 言語コンパイラの将来バージョンでは $GOPATH/pkg を廃止する予定があるようで，その場合にはソースコード・キャッシュの置き場が変更される可能性がある。

モジュール対応モード in Travis CI

CI (Continuous Integration) サービスのひとつである Travis CI は Go 言語にも対応しているが，処理対象のパッケージを $GOPATH/src 以下に展開するため GOPATH モードで処理が走ってしまう。そこで .travis.yml ファイルを以下のように書き換えて強引にモジュール対応モードにする。

language: go

go:
- "1.12.x"

env:
  global:
  - GO111MODULE=on

install:
- go mod download

script:
- go test ./...

環境変数の設定部分に注目してほしい。

GoReleaser による Deploy

GoReleaser を使って複数の実行モジュールをビルドするには .goreleaser.yml ファイルの builds 項目に環境変数の設定を追加しておけば安心である。

builds:
- env:
  - GO111MODULE=on

Travis CI で GoReleaser を使って deploy を行うには .travis.yml ファイルを以下のように記述すれば良い。

language: go

go:
- "1.12.x"

env:
  global:
  - GO111MODULE=on

install:
- go mod download

script:
- go test ./...

deploy:
- provider: script
  skip_cleanup: true
  script: curl -sL https://git.io/goreleaser | bash
  on:
    tags: true
    condition: $TRAVIS_OS_NAME = linux

モジュール・パスとパッケージ・パスが一致しない場合

先ほど少し紹介したが gopkg.in/russross/blackfriday.v2 パッケージをモジュールとして記述する例を挙げてみる⁷。

まず以下のコードを書く。ファイル名は md2html.go とでもしておこう。

package main

import (
    "fmt"
    "io/ioutil"
    "os"

    "gopkg.in/russross/blackfriday.v2"
)

func main() {
    md, err := ioutil.ReadFile(os.Args[1])
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        return
    }

    html := blackfriday.Run(md)
    fmt.Println(string(html))
}

md2html.go に対して以下のようにモジュール定義を行う。

module md2html

require gopkg.in/russross/blackfriday.v2 latest

では実際にコンパイル&実行してみよう。

$ go run md2html.go hello.md
go: finding gopkg.in/russross/blackfriday.v2 v2.0.1
go: gopkg.in/russross/blackfriday.v2@v2.0.1: go.mod has non-....v2 module path "github.com/russross/blackfriday/v2" at revision v2.0.1
go: error loading module requirements

おおう。エラーになってしまった。 github.com/russross/blackfriday/v2 なんてパスはねーよ！とお怒りのようだ。

パス名 gopkg.in/russross/blackfriday.v2 は github.com/russross/blackfriday の alias で v2 のコードは v2 ブランチで管理されている。 v2 ブランチにある go.mod ファイルを見てみると

module github.com/russross/blackfriday/v2

と記されているが，実際に v2 ブランチの github.com/russross/blackfriday に v2 ディレクトリは存在しない。このパスの不一致がエラーの原因のようである。

この不一致を解消するために replace を追加する。具体的には以下のように記述する。

module md2html

require gopkg.in/russross/blackfriday.v2 latest
replace gopkg.in/russross/blackfriday.v2 latest => github.com/russross/blackfriday/v2 latest

では，この状態でコンパイル&実行してみよう。

$ go run md2html.go hello.md
go: finding github.com/russross/blackfriday/v2 v2.0.1
go: downloading github.com/russross/blackfriday/v2 v2.0.1
go: finding github.com/shurcooL/sanitized_anchor_name latest
go: downloading github.com/shurcooL/sanitized_anchor_name v0.0.0-20170918181015-86672fcb3f95
<h1>Hello</h1>

<p>Hello, World!</p>

というわけでうまく動作したようだ。

バージョンを指定して go get を実行する

【追記 2019-02-26】 Go 1.12 からはダミーの go.mod ファイルは必要なくなった。任意の場所で go get コマンドを起動できる。ブラボー！

たとえば私の自作ツールである gpgpdump を自前でビルドすることを考える。

GOPATH モードでパッケージをダウンロードし実行ファイルをビルドするには以下のコマンドを実行すればよい。

$ go get -v github.com/spiegel-im-spiegel/gpgpdump/cli/gpgpdump
github.com/spiegel-im-spiegel/gpgpdump (download)
github.com/spiegel-im-spiegel/gocli (download)
vendor/golang_org/x/net/dns/dnsmessage
github.com/spiegel-im-spiegel/gocli/exitcode
github.com/spiegel-im-spiegel/gocli/rwi
github.com/inconshreveable/mousetrap
net
github.com/spf13/pflag
github.com/spf13/cobra
github.com/spiegel-im-spiegel/gpgpdump/cli/gpgpdump/facade
github.com/spiegel-im-spiegel/gpgpdump/cli/gpgpdump

ダウンロードした github.com/spiegel-im-spiegel/gpgpdump パッケージのソースコードとコンパイル結果（実行ファイルを含む）は $GOPATH 以下に格納される。

では，モジュール対応モードでバージョンを指定して gpgpdump をビルドしてみよう。

$ export GO111MODULE=on

$ go get github.com/spiegel-im-spiegel/gpgpdump/cli/gpgpdump@latest
go: finding github.com/spiegel-im-spiegel/gpgpdump/cli/gpgpdump latest
go: finding github.com/spiegel-im-spiegel/gpgpdump/cli latest
go: finding github.com/spiegel-im-spiegel/gpgpdump v0.3.9
go: downloading github.com/spiegel-im-spiegel/gpgpdump v0.3.9
go: extracting github.com/spiegel-im-spiegel/gpgpdump v0.3.9
go: finding github.com/pkg/errors v0.8.1
go: finding github.com/spf13/pflag v1.0.3
go: finding github.com/BurntSushi/toml v0.3.1
go: finding github.com/spiegel-im-spiegel/gocli v0.9.1
go: finding github.com/spf13/cobra v0.0.3
go: finding github.com/inconshreveable/mousetrap v1.0.0
go: finding golang.org/x/crypto v0.0.0-20190208162236-193df9c0f06f
go: finding github.com/mattn/go-isatty v0.0.4
go: downloading github.com/spiegel-im-spiegel/gocli v0.9.1
go: downloading github.com/spf13/cobra v0.0.3
go: downloading github.com/pkg/errors v0.8.1
go: downloading golang.org/x/crypto v0.0.0-20190208162236-193df9c0f06f
go: downloading github.com/BurntSushi/toml v0.3.1
go: extracting github.com/spiegel-im-spiegel/gocli v0.9.1
go: extracting github.com/pkg/errors v0.8.1
go: extracting github.com/BurntSushi/toml v0.3.1
go: extracting github.com/spf13/cobra v0.0.3
go: downloading github.com/spf13/pflag v1.0.3
go: downloading github.com/inconshreveable/mousetrap v1.0.0
go: extracting golang.org/x/crypto v0.0.0-20190208162236-193df9c0f06f
go: extracting github.com/inconshreveable/mousetrap v1.0.0
go: extracting github.com/spf13/pflag v1.0.3

おおっ，上手くいった。ソースコードは $GOPATH/pkg/mod 以下に，ビルド結果の実行ファイルは $GOPATH/bin に格納されるようだ。

ちなみに path@version 形式でモジュールを指定できるのは go get コマンドのみらしい。

$ go run github.com/spiegel-im-spiegel/gpgpdump/cli/gpgpdump@latest
package github.com/spiegel-im-spiegel/gpgpdump/cli/gpgpdump@latest: can only use path@version syntax with 'go get'

ただし，バージョン指定を省略して latest バージョンで go build や go run コマンドを使うことはできるようだ。

$ go clean -modcache

$ go run github.com/spiegel-im-spiegel/gpgpdump/cli/gpgpdump -h
go: finding github.com/spiegel-im-spiegel/gpgpdump/cli/gpgpdump latest
go: finding github.com/spiegel-im-spiegel/gpgpdump/cli latest
go: finding github.com/spiegel-im-spiegel/gpgpdump v0.3.9
go: downloading github.com/spiegel-im-spiegel/gpgpdump v0.3.9
go: extracting github.com/spiegel-im-spiegel/gpgpdump v0.3.9
go: finding github.com/spiegel-im-spiegel/gocli v0.9.1
go: finding github.com/spf13/cobra v0.0.3
go: finding github.com/spf13/pflag v1.0.3
go: finding github.com/BurntSushi/toml v0.3.1
go: finding github.com/pkg/errors v0.8.1
go: finding github.com/inconshreveable/mousetrap v1.0.0
go: finding golang.org/x/crypto v0.0.0-20190208162236-193df9c0f06f
go: finding github.com/mattn/go-isatty v0.0.4
go: downloading github.com/spiegel-im-spiegel/gocli v0.9.1
go: downloading github.com/pkg/errors v0.8.1
go: downloading golang.org/x/crypto v0.0.0-20190208162236-193df9c0f06f
go: downloading github.com/spf13/cobra v0.0.3
go: downloading github.com/BurntSushi/toml v0.3.1
go: extracting github.com/pkg/errors v0.8.1
go: extracting github.com/spiegel-im-spiegel/gocli v0.9.1
go: extracting github.com/BurntSushi/toml v0.3.1
go: extracting github.com/spf13/cobra v0.0.3
go: extracting golang.org/x/crypto v0.0.0-20190208162236-193df9c0f06f
go: downloading github.com/spf13/pflag v1.0.3
go: downloading github.com/inconshreveable/mousetrap v1.0.0
go: extracting github.com/inconshreveable/mousetrap v1.0.0
go: extracting github.com/spf13/pflag v1.0.3
Usage:
  gpgpdump [flags] [OpenPGP file]

Flags:
  -a, --armor     accepts ASCII input only
      --debug     for debug
  -h, --help      help for gpgpdump
  -i, --int       dumps multi-precision integers
  -j, --json      output with JSON format
  -l, --literal   dumps literal packets (tag 11)
  -m, --marker    dumps marker packets (tag 10)
  -p, --private   dumps private packets (tag 60-63)
  -t, --toml      output with TOML format
  -u, --utc       output with UTC time
  -v, --version   output version of gpgpdump

こりゃあ，便利だ。上手く活用しましょう。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

「GOPATH モード」および「モジュール対応モード」の名称は “Command go” の記述から抜き出した。 Go 言語って用語の表記に微妙なブレがあるのがイマイチだよなぁ。 ↩︎
リビジョン番号によるバージョン管理も可能だが， v0.0.0-20180816225734-aabede6cba87 のような擬似バージョン番号に置き換えられるため，モジュールのインポート時の運用が煩雑になり推奨できない。 ↩︎
異なるメジャーバージョンを同一ディレクトリの同一ブランチで管理していると go.mod のバージョン番号部分に勝手に “+incompatible” が付加されてめっさカッコ悪くなる（笑） ↩︎
/dev/null ファイルの仮定は Go 1.12 から有効になっている。 ↩︎
バージョンに latest を指定すると，コンパイラ側で最新バージョン（またはリビジョン）を探して，最新の番号に置き換えてくれる。 go build や go test などを実行するたびに go.mod ファイルの latest 表記が書き換えられるので注意すること。 ↩︎
Windows 環境では $GOCACHE の既定値は %USERPROFILE%\AppData\Local\go-build となっているようだ。 ↩︎
gopkg.in/russross/blackfriday.v2 パッケージは Markdown コードを HTML 等の書式に変換するパッケージである（参考：Markdown パーサ blackfriday.v2 で遊ぶ）。 ↩︎

Go 1.11 のリリースと「モジュール」機能の実験的サポート

2018-09-26T04:53:04+00:00

1ヶ月も前の話で申し訳ないが，先月末に Go 言語コンパイラ 1.11 がリリースされた。

主な変更点は以下の2つ。

WebAssembly へのコンパイルをサポート
「モジュール」機能の実験的サポート

このうち，今回は「モジュール」機能のサポートについて簡単に紹介する。

「モジュール」とは，これまで vgo (Versioned Go) として開発が進められてきたもので

vgo (Versioned Go) に関する覚え書き

この成果が正式に組み込まれる。バージョン 1.11 で「モジュール」機能を有効にするには環境変数 GO111MODULE を on または auto にセットする。

ちなみに，環境変数 GO111MODULE を auto にセットした場合， GOPATH 下のコードについては以前と同じように動作するが，それ以外の場所では「モジュール」機能が有効になる。 1.11 では環境変数 GO111MODULE が既定で auto になっている。

試しに以下のソースファイル hello.go を適当なフォルダに作成する。

package main

import (
    "fmt"

    "rsc.io/quote"
)

func main() {
    fmt.Println(quote.Hello())
}

これを実行しても rsc.io/quote パッケージがないと怒られてコンパイルエラーになる。ここまでは従来どおりの動作。

次に以下のコマンドを実行する。

$ go mod init hello
go: creating new go.mod: module hello

このコマンドで go.mod ファイルが生成される。中身は以下の通り。

module hello

これで hello.go ファイルはモジュール hello のコードとして定義された。

モジュール名はパッケージのインポート・パスと同じくリポジトリのパスと連動している。たとえば hello.go ファイルをリポジトリ https://github.com/spiegel-im-spiegel/hello で公開・管理するなら，モジュール名も github.com/spiegel-im-spiegel/hello となる。

では，この状態でコードを実行してみよう。

$ go run hello.go
go: finding rsc.io/quote v1.5.2
go: downloading rsc.io/quote v1.5.2
go: finding rsc.io/sampler v1.3.0
go: finding golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c
go: downloading rsc.io/sampler v1.3.0
go: downloading golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c
Hello, world.

自動的に rsc.io/quote およびその依存パッケージがモジュールとして読み込まれていることが分かると思う。このとき go.mod ファイルを見ると

module hello

require rsc.io/quote v1.5.2

依存モジュールおよびそのバージョンの記述が追加されていることが分かる。モジュール間の依存関係を見るには以下のコマンドを実行する¹。

$ go mod graph
hello rsc.io/quote@v1.5.2
rsc.io/quote@v1.5.2 rsc.io/sampler@v1.3.0
rsc.io/sampler@v1.3.0 golang.org/x/text@v0.0.0-20170915032832-14c0d48ead0c

ちなみに，読み込まれたモジュールの実体は $GOPATH/mod フォルダ以下に格納されている。

更に go.mod ファイルを以下のように書き換えてみよう。

module hello

require (
	golang.org/x/text v0.3.0
	rsc.io/quote v1.5.2
)

この状態で，再び実行してみる。

$ go run hello.go
go: finding golang.org/x/text v0.3.0
go: downloading golang.org/x/text v0.3.0
Hello, world.

golang.org/x/text モジュールの v0.3.0 が読み込まれていることが分かる。

既存のパッケージをモジュールとして定義する際， dep で管理していると移行がスムーズになる。自作の gpgpdump で試してみよう。

まずはリポジトリの内容を適当なフォルダに展開し go.mod ファイルを作成する。

$ go mod init github.com/spiegel-im-spiegel/gpgpdump
go: creating new go.mod: module github.com/spiegel-im-spiegel/gpgpdump
go: copying requirements from Gopkg.lock

依存情報を dep の Gopkg.lock ファイルから取得しているのが分かるだろう。生成された go.mod ファイルの内容は以下の通り。

module github.com/spiegel-im-spiegel/gpgpdump

require (
	github.com/BurntSushi/toml v0.3.0
	github.com/inconshreveable/mousetrap v1.0.0
	github.com/pkg/errors v0.8.0
	github.com/spf13/cobra v0.0.3
	github.com/spf13/pflag v1.0.2
	github.com/spiegel-im-spiegel/gocli v0.8.0
	golang.org/x/crypto v0.0.0-20180816225734-aabede6cba87
)

新しいバージョンがリリースされていないか調べる場合は以下のコマンドを実行する。

$ go list -m -u all
go: finding github.com/pkg/errors v0.8.0
go: finding github.com/spf13/pflag v1.0.2
go: finding github.com/spf13/cobra v0.0.3
go: finding github.com/BurntSushi/toml v0.3.0
go: finding github.com/spiegel-im-spiegel/gocli v0.8.0
go: finding github.com/inconshreveable/mousetrap v1.0.0
go: finding golang.org/x/crypto v0.0.0-20180816225734-aabede6cba87
go: finding golang.org/x/crypto latest
go: finding github.com/BurntSushi/toml v0.3.1
github.com/spiegel-im-spiegel/gpgpdump
github.com/BurntSushi/toml v0.3.0 [v0.3.1]
github.com/inconshreveable/mousetrap v1.0.0
github.com/pkg/errors v0.8.0
github.com/spf13/cobra v0.0.3
github.com/spf13/pflag v1.0.2
github.com/spiegel-im-spiegel/gocli v0.8.0
golang.org/x/crypto v0.0.0-20180816225734-aabede6cba87 [v0.0.0-20180910181607-0e37d006457b]

この情報を元に go.mod ファイルを書き換えてみる。

module github.com/spiegel-im-spiegel/gpgpdump

require (
	github.com/BurntSushi/toml v0.3
	github.com/inconshreveable/mousetrap v1.0.0
	github.com/pkg/errors v0.8.0
	github.com/spf13/cobra v0.0.3
	github.com/spf13/pflag v1.0.2
	github.com/spiegel-im-spiegel/gocli v0.8.0
	golang.org/x/crypto latest
)

これで最新モジュールを取得できる。

$ go mod download
go: finding golang.org/x/crypto latest

取得後の go.mod ファイルは以下のように書き換えられる。

module github.com/spiegel-im-spiegel/gpgpdump

require (
	github.com/BurntSushi/toml v0.3.1
	github.com/inconshreveable/mousetrap v1.0.0
	github.com/pkg/errors v0.8.0
	github.com/spf13/cobra v0.0.3
	github.com/spf13/pflag v1.0.2
	github.com/spiegel-im-spiegel/gocli v0.8.0
	golang.org/x/crypto v0.0.0-20180910181607-0e37d006457b
)

んー。これで dep からの置き換えができそうかな。ようやく「GOPATH 汚染問題」が解消されるかねぇ。

【2018-10-04 追記】 Go 1.11.1 がリリース

“go1.11.1 (released 2018/10/01) includes fixes to the compiler, documentation, go command, runtime, and the crypto/x509, encoding/json, go/types, net, net/http, and reflect packages. See the Go 1.11.1 milestone on our issue tracker for details.”

Release History - The Go Programming Languageより

【2018-11-03 追記】 Go 1.11.2 がリリース

“go1.11.2 (released 2018/11/02) includes fixes to the compiler, linker, documentation, go command, and the database/sql and go/types packages. See the Go 1.11.2 milestone on our issue tracker for details.”

Release History - The Go Programming Languageより

ブックマーク

参考図書

image = “/images/attention/go-logo_blue.png”

是非とも dot 言語で出力してほしい。 ↩︎

Go 1.10.3 および 1.9.7 がリリース

2018-06-24T07:55:53+00:00

3週間前の話でゴメンペコン。

Go 言語コンパイラの 1.10.3 と 1.9.7 がリリースされている。

Go 1.10.3 and Go 1.9.7 are released - Google Group
- Go 1.10.3 milestone

These releases include fixes to the go command, and to the crypto/tls, crypto/x509, and strings packages. In particular, they add minimal support to the go command for the vgo transition.

via Go 1.10.3 and Go 1.9.7 are released

ちうわけで Web 関連や暗号関連の製品を手がけている人はご注意を。 vgo サポートについての詳細は以下を参考にするといいだろう。

cmd/go: add minimal module-awareness for legacy operation

なお vgo の考え方については以下を参考にどうぞ。

vgo (Versioned Go) に関する覚え書き

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

vgo (Versioned Go) に関する覚え書き

2018-02-24T07:10:44+00:00

Go 言語の次のバージョン（v1.11）から vgo (Versioned Go) を実装する計画があるようで， vgo 関連のドキュメントが公開されている。

research!rsc: Go & Versioning

vgo は新しいパッケージのバージョン管理機能で，vendoring 機能を使った dep や glide のような仕組みとは異なるアプローチらしい。まず v1.11 で試験的に導入し， v1.12 で正式に導入することを目指しているようだ。最終的に vgo が従来の go コマンドから完全に置き換えられることになれば go get を削除することも考えてるみたい。

I would like Go 1.11 to ship with preliminary support for Go modules, as a kind of technology preview, and then I'd like Go 1.12 to ship with official support. In some later release, we'll remove support for the old, unversioned go get. That's an aggressive schedule, though, and if getting the functionality right means waiting for later releases, we will.

via Go += Package Versioning

お試し vgo

vgo のプロトタイプ版があるようなのでちょっとだけ試してみる。なお，以下は “A Tour of Versioned Go” からの拝借なのでご注意を。

vgo のプロトタイプ版は go get で取得できる。

$ go get -u golang.org/x/vgo

次に以下のコードを用意する¹。

package main // import "github.com/spiegel-im-spiegel/hello"

import (
    "fmt"

    "rsc.io/quote"
)

func main() {
    fmt.Println(quote.Hello())
}

ファイル名は hello.go とする。次に hello.go を置いているフォルダに空の go.mod ファイルを作る。

$ echo>go.mod

これで準備完了。それじゃあ，いきなり vgo build してみよう。

$ vgo build
vgo: resolving import "rsc.io/quote"
vgo: finding rsc.io/quote (latest)
vgo: adding rsc.io/quote v1.5.2
vgo: finding rsc.io/quote v1.5.2
vgo: finding rsc.io/sampler v1.3.0
vgo: finding golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c
vgo: downloading rsc.io/quote v1.5.2
vgo: downloading rsc.io/sampler v1.3.0
vgo: downloading golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c

v1.5.2 といったバージョンはパッケージのリポジトリのタグ情報から取得する。バージョンを示すタグ情報がない場合は v0.0.0-20170915032832-14c0d48ead0c のような感じで仮バージョンが付与される。

では，作成した実行バイナリを動かしてみる（この記事では Windows 環境なので悪しからず）。

$ hello.exe
Hello, world.

$ SET LANG=ja

$ hello.exe
こんにちは世界。

おおー。ちゃんと動いてる。

ビルド後，空の go.mod ファイルに以下のように記述が加えられた。

module "github.com/spiegel-im-spiegel/hello"

require "rsc.io/quote" v1.5.2

vgo のパッケージ管理

ビルドの様子を見ればわかると思うが，依存関係を調べて各パッケージを全てダウンロードしている。実は golang.org/x/text パッケージは GOPATH 配下にダウンロード済みだったのだが，これを使ってはいないようだ。

じゃあ，ダウンロードしたパッケージは何処にあるかというと $GOPATH/src/v フォルダ以下に展開されていた²。

$GOPATH/src/v
├─cache
│  ├─golang.org
│  │  └─x
│  │      └─text
│  │          └─@v
│  └─rsc.io
│      ├─quote
│      │  └─@v
│      └─sampler
│          └─@v
├─golang.org
│  └─x
│      └─text@v0.0.0-20170915032832-14c0d48ead0c
└─rsc.io
    ├─quote@v1.5.2
    └─sampler@v1.3.0

更に quote@v1.5.2 フォルダと sampler@v1.3.0 フォルダにもそれぞれ go.mod ファイルがあって，以下のような記述になっている。

module "rsc.io/quote"

require "rsc.io/sampler" v1.3.0

module "rsc.io/sampler"

require "golang.org/x/text" v0.0.0-20170915032832-14c0d48ead0c

このように go.mod ファイルの情報を元にして依存パッケージのバージョンを管理するわけだ。ちなみに各パッケージの全てのバージョンを列挙するには以下のコマンドが使える。

$ vgo list -t rsc.io/sampler
rsc.io/sampler
        v1.0.0
        v1.2.0
        v1.2.1
        v1.3.0
        v1.3.1
        v1.99.99

また hello.go 以下の依存パッケージのバージョン情報は以下のコマンドで見ることができる。

$ vgo list -m -u
MODULE                               VERSION                             LATEST
github.com/spiegel-im-spiegel/hello  -                                   -
golang.org/x/text                    v0.0.0-20170915032832-14c0d48ead0c  v0.0.0-20171214130843-f21a4dfb5e38
rsc.io/quote                         v1.5.2 (2018-02-15 00:44)           -
rsc.io/sampler                       v1.3.0 (2018-02-14 04:05)           v1.99.99 (2018-02-14 07:20)

dep みたいに依存関係を可視化できるといいんだけどねえ。

Semantic Versioning と後方互換性

vgo が管理するバージョンは Semantic Versioning に従うことが期待されている。また同じ import パスで取得するパッケージは後方互換性を持つことも期待されている。

たとえば， my/thing パッケージの v2 が後方互換性のない構成になっていた場合は my/thing/v2 という感じに import パスを変えるわけだ³。

via Semantic Import Versioning

現行の Go 言語コンパイラはパッケージのバージョンを意識していないが（バージョン管理は dep のような外部ツールが担っている）， vgo が正式に組み込まれればより厳密な（Semantic Versioning に基づいた）バージョン管理が要求されることになると思う。なので，今からそれを意識した運用を考えておくべきかもしれない。

とはいえ，まだ先の話

とはいえ，次の v1.11 が出るのは早くても半年後（2018年8月頃）だし，正式対応するという v.1.12 など鬼が笑う話である。今後 Semantic Versioning は意識したほうがいいかもしれないが，当面は dep などを用いた運用ができていればいいと思う。

ブックマーク

ソースコードの先頭部分 package main に続くコメント // import ... を正しく書かないとビルド時にエラーになる。 ↩︎
このパスは正式版までに変更されると考えられる。 go.mod ファイルにパッケージへのフルパスが記述されるため，わざわざ GOPATH 配下にパス構成を統合する必要が無いからである。最終的には GOPATH の削除も視野に入れているかもしれない。 ↩︎
あるいは gopkg.in のような API を使う手もある。 ↩︎