List of Vendoring [text.Baldanders.info]

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 言語の依存性管理ツール Dep v0.4 がリリースされていた

2018-03-04T05:18:16+00:00

随分経っているが，忘れないように覚え書きとして残しておく。

2018年1月に dep の v0.4 がリリースされた（2018-03-04 時点で v0.4.1）。随分前の話だが，忘れないように覚え書きとして残しておく。

v0.4 では Gopkg.toml に prune 項目が追加された。 prune は vendor/ フォルダにパッケージを展開する際に除外するファイルを指定できる。以下のように記述する。

[prune]
  unused-packages = true
  go-tests = true

unused-packages は未使用パッケージを除外する。 go-tests はテストコードを除外する。他にも non-go を指定すると Go 言語コード以外のファイルを除外してくれる。

また，パッケージ単位でも

[prune]
  non-go = true

  [[prune.project]]
    name = "github.com/project/name"
    go-tests = true
    non-go = false

という感じに指定できるらしい。

ちなみに dep を Travis CI で使うには .travis.yml で以下のように記述する。

env:
  - DEP_VERSION="0.4.1"

before_install:
  # Download the binary to bin folder in $GOPATH
  - curl -L -s https://github.com/golang/dep/releases/download/v${DEP_VERSION}/dep-linux-amd64 -o $GOPATH/bin/dep
  # Make the binary executable
  - chmod +x $GOPATH/bin/dep

dep のバージョンが上がった場合には DEP_VERSION の値だけ変えればいける（はず）。

ブックマーク

Glide から Dep への移行を検討する

Glide から Dep への移行を検討する

2017-10-10T09:02:56+00:00

（この記事は Qiita とのマルチポストです。まぁ，向こうは草稿版だけど）

久しぶりに glide を使おうと最新版（0.13.0）を見に行ったら “Consider switching to dep” とか書いてあるじゃない。

Glide is used by a great number of projects and will continue to get support for some time. But, the near future is likely in dep. dep can handle importing Glide config files. Please consider trying dep on your project or converting to dep.

via Release 0.13.0

まじすか。

つまり「依存関係（Vendoring）管理ツールとしては dep を推奨するけど移行できない人のために当面はサポートを続けるよ（でも将来は分からん）」という解釈でいいのだろうか。

dep は Go 言語開発プロジェクトの公式ツールで，2017年の始めくらいに日本でも話題になったような気がするが，私は glide で完全に満足していたのでスルーしていた。こんなことになるなんて。ならもう dep に移行するしかないぢゃん。

とはいえ，いきなり本番環境に投入するのは怖いので，なにか適当なテストケースはないか，と自分のリポジトリを漁ってたら丁度いいのがあったよ。

spiegel-im-spiegel/pi: Estimate of Pi with Monte Carlo method.

これってモンテカルロ法で遊んでたときに作ったものだ。最悪ぶっ壊れてもいいので，これ使って試してみるか。

dep の取得

まず dep の取得から始めないとだが，リポジトリ自体は go get コマンドで取得できる。

$ go get -u github.com/golang/dep/cmd/dep

これをこのまま使ってもいいのだが，リリースページにビルド済みのモジュールが置かれているので，ありがたくこれを使わせてもらおう。

最新版（現時点で v0.4.1）には Windows 用のモジュール dep-windows-amd64.exe もある。これを dep.exe にリネームして使う。

万が一があっては困るのでモジュールの SHA256 ハッシュ値を確認しておく（こういうのこそ OpenPGP を使ってくれないものか）。 Windows ユーザで Windows 8.1 以降であれば PowerShell（4.0 以上）で Get-FileHash コマンドレットが使える¹。

PS C:\Users\username\Downloads> Get-FileHash dep-windows-amd64.exe -Algorithm SHA256 | Format-List

Algorithm : SHA256
Hash      : F6E6A872C54D5AE7536AC71FD5BCAC9F4E7B8A1DAFA1EF7C23866E2F3069FE4E
Path      : C:\Users\username\Downloads\dep-windows-amd64.exe

これを dep-windows-amd64.exe.sha256 に記載されている値と比較する。改竄されてなければ同じ値になるはずである。目視は辛いのでテキストエディタ等の検索機能を使えばいいだろう。

【2017-10-31 追記】 だんだん面倒になってきたのでハッシュ値を計算するツールを作った。詳しくは「Hash 値を計算するパッケージを作ってみた」を参照のこと。

実行モジュールの動作確認もしておく。

$ dep
Dep is a tool for managing dependencies for Go projects

Usage: "dep [command]"

Commands:

  init     Set up a new Go project, or migrate an existing one
  status   Report the status of the project's dependencies
  ensure   Ensure a dependency is safely vendored in the project
  prune    Pruning is now performed automatically by dep ensure.
  version  Show the dep version information

Examples:
  dep init                               set up a new project
  dep ensure                             install the project's dependencies
  dep ensure -update                     update the locked versions of all dependencies
  dep ensure -add github.com/pkg/errors  add a dependency to the project

Use "dep help [command]" for more information about a command.

$ dep version
dep:
 version     : v0.4.1
 build date  : 2018-01-24
 git hash    : 37d9ea0a
 go version  : go1.9.1
 go compiler : gc
 platform    : windows/amd64

glide から dep への移行

お試し用の spiegel-im-spiegel/pi をビルド可能な適当な場所に置く。

このパッケージの glide.yaml はこんな感じになっている。

package: github.com/spiegel-im-spiegel/pi
import:
- package: github.com/spiegel-im-spiegel/gocli
- package: github.com/spf13/cobra
- package: github.com/pkg/errors
- package: github.com/seehuhn/mt19937
- package: github.com/davidminor/gorand
- package: github.com/davidminor/uint128

また glide.lock はこんな感じ。

hash: d570123d6231810c51dd17e415673df221fb2dec7ef6ab45cd34093002a87cbb
updated: 2016-11-16T17:28:38.2997832+09:00
imports:
- name: github.com/davidminor/gorand
  version: 189780b8053a44a111339a4248394fd844c1da40
  subpackages:
  - lcg
- name: github.com/davidminor/uint128
  version: 5745f1bf80414e0ad2670e85d6aece8c58031def
- name: github.com/inconshreveable/mousetrap
  version: 76626ae9c91c4f2a10f34cad8ce83ea42c93bb75
- name: github.com/pkg/errors
  version: 248dadf4e9068a0b3e79f02ed0a610d935de5302
- name: github.com/seehuhn/mt19937
  version: 98c0ea580d2f3c5a171acf4d4f15321b72209d08
- name: github.com/spf13/cobra
  version: 6b74a60562f5c1c920299b8f02d153e16f4897fc
- name: github.com/spf13/pflag
  version: 5ccb023bc27df288a957c5e994cd44fd19619465
- name: github.com/spiegel-im-spiegel/gocli
  version: 5929f04fb8e4a19ac29fdf658866f9441f339cd9
testImports: []

この状態で dep init コマンドを実行する。

$ dep init
Importing configuration from glide. These are only initial constraints, and are further refined during the solve process.                                                                             
Detected glide configuration files...                                                              
Converting from glide.yaml and glide.lock...                                                       
  Trying v0.3.0 (5929f04) as initial lock for imported dep github.com/spiegel-im-spiegel/gocli     
  Trying * (6b74a60) as initial lock for imported dep github.com/spf13/cobra                       
  Trying * (248dadf) as initial lock for imported dep github.com/pkg/errors                        
  Trying master (98c0ea5) as initial lock for imported dep github.com/seehuhn/mt19937              
  Trying * (189780b) as initial lock for imported dep github.com/davidminor/gorand                 
  Trying master (5745f1b) as initial lock for imported dep github.com/davidminor/uint128           
  Trying v1.0 (76626ae) as initial lock for imported dep github.com/inconshreveable/mousetrap      
  Trying * (5ccb023) as initial lock for imported dep github.com/spf13/pflag                       
  Locking in  (248dadf) for direct dep github.com/pkg/errors                                       
  Locking in  (6b74a60) for direct dep github.com/spf13/cobra                                      
  Using master as constraint for direct dep github.com/seehuhn/mt19937                             
  Locking in master (98c0ea5) for direct dep github.com/seehuhn/mt19937                            
  Using ^0.3.0 as constraint for direct dep github.com/spiegel-im-spiegel/gocli                    
  Locking in v0.3.0 (5929f04) for direct dep github.com/spiegel-im-spiegel/gocli                   
  Locking in  (189780b) for direct dep github.com/davidminor/gorand

実は spiegel-im-spiegel/gocli パッケージの最新版は v0.5.0 だが， glide.lock の内容を読み取って，ちゃんと v0.3.0 のものを取ってきているようだ。偉いぞ！

dep init コマンドにより Gopkg.toml および Gopkg.lock の2つのファイルと vendor/ フォルダが作成される。このうち Gopkg.toml の内容は以下の通り。

[[constraint]]
  branch = "master"
  name = "github.com/seehuhn/mt19937"

[[constraint]]
  name = "github.com/spiegel-im-spiegel/gocli"
  version = "0.3.0"

[prune]
  go-tests = true
  unused-packages = true

そして Gopkg.lock の内容は以下の通り。

[[projects]]
  name = "github.com/davidminor/gorand"
  packages = ["lcg"]
  revision = "189780b8053a44a111339a4248394fd844c1da40"

[[projects]]
  branch = "master"
  name = "github.com/davidminor/uint128"
  packages = ["."]
  revision = "5745f1bf80414e0ad2670e85d6aece8c58031def"

[[projects]]
  name = "github.com/inconshreveable/mousetrap"
  packages = ["."]
  revision = "76626ae9c91c4f2a10f34cad8ce83ea42c93bb75"
  version = "v1.0"

[[projects]]
  name = "github.com/pkg/errors"
  packages = ["."]
  revision = "248dadf4e9068a0b3e79f02ed0a610d935de5302"

[[projects]]
  branch = "master"
  name = "github.com/seehuhn/mt19937"
  packages = ["."]
  revision = "98c0ea580d2f3c5a171acf4d4f15321b72209d08"

[[projects]]
  name = "github.com/spf13/cobra"
  packages = ["."]
  revision = "6b74a60562f5c1c920299b8f02d153e16f4897fc"

[[projects]]
  name = "github.com/spf13/pflag"
  packages = ["."]
  revision = "5ccb023bc27df288a957c5e994cd44fd19619465"

[[projects]]
  name = "github.com/spiegel-im-spiegel/gocli"
  packages = ["."]
  revision = "5929f04fb8e4a19ac29fdf658866f9441f339cd9"
  version = "v0.3.0"

[solve-meta]
  analyzer-name = "dep"
  analyzer-version = 1
  inputs-digest = "3f9a0c0024e81ba251efaa0cb0014694f8315add84c7e8044a346f370e3e088e"
  solver-name = "gps-cdcl"
  solver-version = 1

glide.lock と Gopkg.lock の内容がマッチしているのが分かると思う。

【2018-02-02 追記】 dep v0.4 から挙動が変わった？どうやら dep init 時点でリビジョン管理が必要と判断されるパッケージのみ Gopkg.toml に記載される感じ。それ以外でリビジョン管理が必要なものは手動で Gopkg.toml に記述する必要があるかも。

念のため dep status も見ておこう。

$ dep status
PROJECT                               CONSTRAINT     VERSION        REVISION  LATEST   PKGS USED
github.com/davidminor/gorand          *                             189780b            1
github.com/davidminor/uint128         branch master  branch master  5745f1b   5745f1b  1
github.com/inconshreveable/mousetrap  v1.0           v1.0           76626ae   v1.0     1
github.com/pkg/errors                 *                             248dadf            1
github.com/seehuhn/mt19937            branch master  branch master  98c0ea5   98c0ea5  1
github.com/spf13/cobra                *                             6b74a60            1
github.com/spf13/pflag                *                             5ccb023            1
github.com/spiegel-im-spiegel/gocli   ^0.3.0         v0.3.0         5929f04   v0.3.0   1

ビルドもちゃんと通る。

$ go build -v .
github.com/spiegel-im-spiegel/pi/vendor/github.com/davidminor/uint128
github.com/spiegel-im-spiegel/pi/vendor/github.com/spf13/pflag
github.com/spiegel-im-spiegel/pi/vendor/github.com/seehuhn/mt19937
github.com/spiegel-im-spiegel/pi/vendor/github.com/inconshreveable/mousetrap
github.com/spiegel-im-spiegel/pi/vendor/github.com/spiegel-im-spiegel/gocli
github.com/spiegel-im-spiegel/pi/vendor/github.com/davidminor/gorand/lcg
github.com/spiegel-im-spiegel/pi/vendor/github.com/pkg/errors
github.com/spiegel-im-spiegel/pi/gencmplx
github.com/spiegel-im-spiegel/pi/qq
github.com/spiegel-im-spiegel/pi/genpi
github.com/spiegel-im-spiegel/pi/plot
github.com/spiegel-im-spiegel/pi/vendor/github.com/spf13/cobra
github.com/spiegel-im-spiegel/pi/estmt
github.com/spiegel-im-spiegel/pi/cmd
github.com/spiegel-im-spiegel/pi

というわけで， glide.yaml と glide.lock が正しい状態で残っていれば問題なく dep に移行できそうだ。

依存関係の管理

Gopkg.toml を以下のように修正してみる。

[[constraint]]
  name = "github.com/davidminor/gorand"
  branch = "master"

[[constraint]]
  name = "github.com/pkg/errors"
  version = "0.8.*"

[[constraint]]
  name = "github.com/seehuhn/mt19937"
  branch = "master"

[[constraint]]
  name = "github.com/spf13/cobra"
  version = "0.0.*"

[[constraint]]
  name = "github.com/spiegel-im-spiegel/gocli"
  version = "0.3.*"

[prune]
  go-tests = true
  unused-packages = true

この状態で dep ensure コマンドを実行しステータスを見ると，以下のような感じになる。

$ dep status
PROJECT                               CONSTRAINT     VERSION        REVISION  LATEST   PKGS USED
github.com/davidminor/gorand          branch master  branch master  283446f   283446f  1
github.com/davidminor/uint128         branch master  branch master  5745f1b   5745f1b  1
github.com/inconshreveable/mousetrap  v1.0           v1.0           76626ae   v1.0     1
github.com/pkg/errors                 ^0.8.0         v0.8.0         645ef00   v0.8.0   1
github.com/seehuhn/mt19937            branch master  branch master  98c0ea5   98c0ea5  1
github.com/spf13/cobra                ^0.0.1         v0.0.1         7b2c5ac   v0.0.1   1
github.com/spf13/pflag                *                             5ccb023            1
github.com/spiegel-im-spiegel/gocli   ^0.3.0         v0.3.0         5929f04   v0.3.0   1

たとえば

[[constraint]]
  name = "github.com/davidminor/gorand"
  branch = "master"

であれば github.com/davidminor/gorand パッケージで master ブランチの最新コミットを取ってくる。また

[[constraint]]
  name = "github.com/spiegel-im-spiegel/gocli"
  version = "0.3.*"

であれば spiegel-im-spiegel/gocli パッケージで v0.3.x の最新バージョンを取ってくる²。

[prune] 指定では vendor/ フォルダから除外するパッケージやファイルを指定する。

[prune]
  go-tests = true
  unused-packages = true

go-tests はテスト用のファイル（*_test.go）を unused-packages は未使用のパッケージを指す。なお，値は true 以外はエラーになるようだ。たとえば未使用パッケージも含めたいのであれば unused-packages = false とするのではなく記述自体を削除する。

[prune]
  go-tests = true

依存関係の視覚化

dep status コマンドには結果を DOT 言語で吐き出すオプションがあるようだ。 Graphviz があれば，この出力結果を画像データに変換できる。

$ dep status -dot | dot -Tpng -o pi-dependency.png

結果はこんな感じ。

pi-dependency.png

ブラボー！

リポジトリへのパスを直接指定する

GitHub みたいな有名 SaaS に置いてあるパッケージなら Gopkg.toml に

[[constraint]]
  name = "github.com/spiegel-im-spiegel/gocli"
  version = "0.3.*"

とか書けば適切に処理してくれるけど，有名でない SaaS ディレクトリや職場 LAN のリポジトリ上のパッケージではこうはいかないこともある。こういう場合には，以下に示す通り，直接リポジトリへの（プロトコルを含めた）パスを指定する。

[[constraint]]
  name = "github.com/spiegel-im-spiegel/gocli"
  source = "git@github.com:spiegel-im-spiegel/gocli.git"
  version = "0.3.* "

これで dep ensure すれば

$ dep ensure -v

...

(1/8) Wrote github.com/spiegel-im-spiegel/gocli (from git@github.com:spiegel-im-spiegel/gocli.git)@v0.3.0
(2/8) Wrote github.com/pkg/errors@248dadf4e9068a0b3e79f02ed0a610d935de5302
(3/8) Wrote github.com/davidminor/gorand@189780b8053a44a111339a4248394fd844c1da40
(4/8) Wrote github.com/spf13/pflag@5ccb023bc27df288a957c5e994cd44fd19619465
(5/8) Wrote github.com/inconshreveable/mousetrap@v1.0
(6/8) Wrote github.com/davidminor/uint128@master
(7/8) Wrote github.com/spf13/cobra@6b74a60562f5c1c920299b8f02d153e16f4897fc
(8/8) Wrote github.com/seehuhn/mt19937@master

といった感じになる。ちゃんと指定したリポジトリからパッケージを取得してきているのが分かるだろう。

Go 1.9 から glide novendor は必要なくなった

Vendoring で一番あつかいに困るのがテストで，たとえば安直に

$ go test -v ./...

とかやると vendor/ フォルダ以下のパッケージまでテスト・シーケンスが走ってしまうのが困りものであった。このため glide にはこれを回避する glide novendor コマンドがあって

$ go test -v $(glide novendor)

とすることで vendor/ フォルダへのテストを回避できるようになっていたのだ³。

ところがところが！！

Go 言語 1.9 からは ./... の扱いが変更になり

“By popular request, ./... no longer matches packages in vendor directories in tools accepting package names, such as go test.”

via Go 1.9 Release Notes

ということで ./... に vendor/ フォルダ以下が含まれないことになったのだ。たとえば spiegel-im-spiegel/pi パッケージの場合は

$ go list ./...
github.com/spiegel-im-spiegel/pi
github.com/spiegel-im-spiegel/pi/cmd
github.com/spiegel-im-spiegel/pi/estmt
github.com/spiegel-im-spiegel/pi/gencmplx
github.com/spiegel-im-spiegel/pi/genpi
github.com/spiegel-im-spiegel/pi/plot
github.com/spiegel-im-spiegel/pi/qq

となる。逆に vendor/ フォルダも含めたいなら

$ go list ./... ./vendor/...
github.com/spiegel-im-spiegel/pi
github.com/spiegel-im-spiegel/pi/cmd
github.com/spiegel-im-spiegel/pi/estmt
github.com/spiegel-im-spiegel/pi/gencmplx
github.com/spiegel-im-spiegel/pi/genpi
github.com/spiegel-im-spiegel/pi/plot
github.com/spiegel-im-spiegel/pi/qq
github.com/spiegel-im-spiegel/pi/vendor/github.com/davidminor/gorand/lcg
github.com/spiegel-im-spiegel/pi/vendor/github.com/davidminor/gorand/pcg
github.com/spiegel-im-spiegel/pi/vendor/github.com/davidminor/uint128
github.com/spiegel-im-spiegel/pi/vendor/github.com/inconshreveable/mousetrap
github.com/spiegel-im-spiegel/pi/vendor/github.com/pkg/errors
github.com/spiegel-im-spiegel/pi/vendor/github.com/seehuhn/mt19937
github.com/spiegel-im-spiegel/pi/vendor/github.com/spf13/cobra
github.com/spiegel-im-spiegel/pi/vendor/github.com/spf13/cobra/cobra
github.com/spiegel-im-spiegel/pi/vendor/github.com/spf13/cobra/cobra/cmd
github.com/spiegel-im-spiegel/pi/vendor/github.com/spf13/cobra/doc
github.com/spiegel-im-spiegel/pi/vendor/github.com/spf13/pflag
github.com/spiegel-im-spiegel/pi/vendor/github.com/spiegel-im-spiegel/gocli

とすればよい。こっちのほうが遥かに扱いやすいよね。

これでまたひとつ glide が「要らない子」になる理由が増えてしまったのだった。

ブックマーク

Windows 7 の場合は “Windows Management Framework 4.0” をインストールすることで PowerShell 4.0 にアップグレードできる。 ↩︎
Gopkg.toml のバージョンの考え方は “Semantic Versioning” に従っている。ワイルドカード等を使ったバージョン指定については Masterminds/semver パッケージを参照するとよい。 ↩︎
glide を使わない場合は go test -v $(go list ./... | grep -v /vendor/) とかする。どのみち Windows のコマンドプロンプトでは無理だけど（笑） ↩︎

Glide で Vendoring

2015-12-07T14:30:21+00:00

【2017-10-10 追記】 glide プロジェクトは Vendoring ツールとして公式ツールの dep を推し始めたようである。

Glide から Dep への移行を検討する

そこで当セクションでも今後は dep を推していくことにする。この記事はメンテナンスされない可能性があるが，あしからずご了承の程を。

以前「GOPATH 汚染問題」で Go 言語 1.5 の vendoring 機能を紹介したが，この vendoring のヘルパ・ツールと言えるのが glide である。 glide では依存する外部パッケージの情報を YAML 形式の定義ファイルに記述し，この定義ファイルを基に外部パッケージの管理を行う。

（glide 0.8 から挙動が少し変わった。この記事では 0.8.2 を使っている）

Glide のインストール

glide は自身も glide で外部パッケージを管理している。なので最初は go get ではなく Releases ページからビルド済みのものを取得することをお勧めする¹。

既に glide が利用可能な状態なら，以下の要領でビルドできる。

C:\workspace\glide>SET GOPATH=C:\workspace\glide

C:\workspace\glide>SET GO15VENDOREXPERIMENT=1

C:\workspace\glide>git clone git@github.com:Masterminds/glide.git src\github.com\Masterminds\glide
Cloning into 'src\github.com\Masterminds\glide'...
remote: Counting objects: 2292, done.
remote: Compressing objects: 100% (65/65), done.
remote: Total 2292 (delta 34), reused 0 (delta 0), pack-reused 2292
Receiving objects: 100% (2292/2292), 468.01 KiB | 397.00
Receiving objects: 100% (2292/2292), 537.97 KiB | 397.00 KiB/s, done.
Resolving deltas: 100% (1578/1578), done.
Checking connectivity... done.

C:\workspace\glide>pushd src\github.com\Masterminds\glide

C:\workspace\glide\src\github.com\Masterminds\glide>glide install
[INFO] Fetching updates for github.com/codegangsta/cli.
[INFO] Fetching updates for github.com/Masterminds/cookoo.
[INFO] Fetching updates for github.com/Masterminds/vcs.
[INFO] Fetching updates for gopkg.in/yaml.v2.
[INFO] Fetching updates for github.com/Masterminds/semver.
[INFO] Setting version for github.com/Masterminds/cookoo to 78aa11ce75e257c51be7ea945edb84cf19c4a6de.
[INFO] Setting version for github.com/Masterminds/semver to 6333b7bd29aad1d79898ff568fd90a8aa533ae82.
[INFO] Setting version for github.com/codegangsta/cli to b5232bb2934f606f9f27a1305f1eea224e8e8b88.
[INFO] Setting version for github.com/Masterminds/vcs to eaee272c8fa4514e1572e182faecff5be20e792a.
[INFO] Setting version for gopkg.in/yaml.v2 to f7716cbe52baa25d2e9b0d0da546fcf909fc16b4.

C:\workspace\glide\src\github.com\Masterminds\glide>popd

C:\workspace\glide>go install -v ./...
github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo/io
github.com/Masterminds/glide/msg
github.com/Masterminds/glide/gb
github.com/Masterminds/glide/vendor/gopkg.in/yaml.v2
github.com/Masterminds/glide/vendor/github.com/Masterminds/semver
github.com/Masterminds/glide/vendor/github.com/codegangsta/cli
github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo/safely
github.com/Masterminds/glide/vendor/github.com/Masterminds/vcs
github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo
github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo/cli
github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo/database/sql
github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo/database/active
github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo/convert
github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo/fmt
github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo/web
github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo/example
github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo/log
github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo/web/auth
github.com/Masterminds/glide/util
github.com/Masterminds/glide/vendor/github.com/Masterminds/cookoo/doc
github.com/Masterminds/glide/cfg
github.com/Masterminds/glide/dependency
github.com/Masterminds/glide/cmd
github.com/Masterminds/glide

C:\workspace\glide>bin\glide.exe -v
glide version dev

簡単な使い方は以下の通り。

C:> glide -h
NAME:
   glide - The lightweight vendor package manager for your Go projects.

Each project should have a 'glide.yaml' file in the project directory. Files
look something like this:

        package: github.com/Masterminds/glide
        imports:
                - package: github.com/Masterminds/cookoo
                  vcs: git
                  ref: 1.1.0
                  subpackages: **
                - package: github.com/kylelemons/go-gypsy
                  subpackages: yaml
                        flatten: true

NOTE: As of Glide 0.5, the commands 'in', 'into', 'gopath', 'status', and 'env'
no longer exist.


USAGE:
   glide [global options] command [command options] [arguments...]

VERSION:
   0.8.2

COMMANDS:
   create, init Initialize a new project, creating a glide.yaml file
   get          Install one or more packages into `vendor/` and add dependency to glide.yaml.
   import       Import files from other dependency management systems.
   name         Print the name of this project.
   novendor, nv List all non-vendor paths in a directory.
   rebuild      Rebuild ('go build') the dependencies
   install, i   Install a project's dependencies
   update, up   Update a project's dependencies
   tree         Tree prints the dependencies of this project as a tree.
   list         List prints all dependencies that Glide could discover.
   about        Learn about Glide
   help, h      Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --yaml, -y "glide.yaml"              Set a YAML configuration file.
   --quiet, -q                          Quiet (no info or debug messages)
   --debug                              Print Debug messages (verbose)
   --home "C:\Users\username\.glide"    The location of Glide files [$GLIDE_HOME]
   --no-color                           Turn off colored output for log messages
   --help, -h                           show help
   --version, -v                        print the version

開発環境の準備

動作検証用に「GOPATH 汚染問題」で使ったコードを利用する。まず，以下の環境を作る。

C:\workspace\vdemo2>SET GOPATH=C:\workspace\vdemo2

C:\workspace\vdemo2>SET GO15VENDOREXPERIMENT=1

C:\workspace\vdemo2>tree /f .
C:\WORKSPACE\VDEMO2
└─src
    └─julian-day
            julian-day.go

julian-day.go の内容は以下のとおりである。

package main

import (
    "flag"
    "fmt"
    "os"
    "strconv"
    "time"

    "github.com/spiegel-im-spiegel/astrocalc/modjulian"
)

func main() {
    //引数のチェック
    flag.Parse()
    argsStr := flag.Args()
    if len(argsStr) < 3 {
        fmt.Fprintln(os.Stderr, "年月日を指定してください")
        return
    }
    args := make([]int, 3)
    for i := 0; i < 3; i++ {
        num, err := strconv.Atoi(argsStr[i])
        if err != nil {
            fmt.Fprintln(os.Stderr, err)
            return
        }
        args[i] = num
    }
    tm := time.Date(args[0], time.Month(args[1]), args[2], 0, 0, 0, 0, time.UTC)
    fmt.Printf("%v\n", tm)
    fmt.Printf("MJD = %d日\n", modjulian.DayNumber(tm))
}

当然ながら，このままビルドしても外部パッケージがないため失敗する。

C:\workspace\vdemo2>go install ./...
src\julian-day\julian-day.go:10:2: cannot find package "github.com/spiegel-im-spiegel/astrocalc/modjulian" in any of:
        C:\Go\src\github.com\spiegel-im-spiegel\astrocalc\modjulian (from $GOROOT)
        C:\workspace\vdemo2\src\github.com\spiegel-im-spiegel\astrocalc\modjulian (from $GOPATH)

依存関係を定義する

開発環境ができたら，パッケージのフォルダ（今回は src/julian-day）に移動し， glide create コマンドで依存関係を定義する glide.yaml ファイルを生成する。

C:\workspace\vdemo2>pushd src\julian-day

C:\workspace\vdemo2\src\julian-day>glide create
[INFO] Generating a YAML configuration file and guessing the dependencies
[INFO] Attempting to import from other package managers (use --skip-import to skip)
[INFO] Found reference to github.com\spiegel-im-spiegel\astrocalc\modjulian

C:\workspace\vdemo2\src\julian-day>tree /f C:\workspace\vdemo2
C:\WORKSPACE\VDEMO2
└─src
    └─julian-day
            glide.yaml
            julian-day.go

ソースコードを読んで glide.yaml に必要な情報を推測して書いてくれているようだが²，デリミタが “/” じゃなくて “\” になってる。 Windows 環境だからかな。残念 orz

package: julian-day
import:
- package: github.com\spiegel-im-spiegel\astrocalc\modjulian

astrocalc/modjulian パッケージのパスを修正して、更にバージョン情報を追加する。

package: julian-day
import:
- package: github.com/spiegel-im-spiegel/astrocalc/modjulian
  version: v0.1.0

これで go get コマンドと同じように， package のパスから自動的に repository を判別してパッケージを取得できる。 go get コマンドと異なるのは， glide.yaml ファイルで指定した version 情報から適切な revision を選択できる点である³。

また，以下のように VCS (Version Control System) の種類⁴ と URI を明示的に指定することもできる（vcs と repo は必ずセットで指定する）。

package: julian-day
import:
- package: github.com/spiegel-im-spiegel/astrocalc/modjulian
  vcs:     git
  repo:    git@github.com:spiegel-im-spiegel/astrocalc.git
  version: v0.1.0

たとえば，プライベートな bare repository からインポートする場合には，この方法が有効である。

パッケージの取得とビルド

パッケージの取得には glide update または glide up コマンドを起動する。

C:\workspace\vdemo2\src\julian-day>glide up
[INFO] Fetching updates for github.com/spiegel-im-spiegel/astrocalc.
[INFO] Setting version for github.com/spiegel-im-spiegel/astrocalc to v0.1.0.
[INFO] Scanning github.com/spiegel-im-spiegel/astrocalc for dependencies.
[INFO] Setting version for github.com/spiegel-im-spiegel/astrocalc to v0.1.0.
[INFO] Project relies on 1 dependencies.
[INFO] Writing glide.lock file
C:\workspace\vdemo2\src\julian-day>tree /f C:\workspace\vdemo2
C:\WORKSPACE\VDEMO2
└─src
    └─julian-day
        │  glide.lock
        │  glide.yaml
        │  julian-day.go
        │
        └─vendor
            └─github.com
                └─spiegel-im-spiegel
                    └─astrocalc
                        │  .editorconfig
                        │  .gitignore
                        │  .travis.yml
                        │  LICENSE
                        │  README.md
                        │
                        └─modjulian
                                example_test.go
                                LICENSE
                                modjulian.go
                                modjulian_test.go

これでビルドが可能になった。ではビルドしようかな。

C:\workspace\vdemo2\src\julian-day>popd

C:\workspace\vdemo2>go install -v  ./...
julian-day/vendor/github.com/spiegel-im-spiegel/astrocalc/modjulian
julian-day

C:\workspace\vdemo2>bin\julian-day.exe 2015 1 1
2015-01-01 00:00:00 +0000 UTC
MJD = 57023日

よーし，うむうむ，よーし。

Vendor フォルダの管理

glide.lock ファイルには外部パッケージの状態が記述されている。

hash: b1eecd43769aa1225f7b8922a35566008561c64f4ce11180f299888ed153ad69
updated: 2015-12-23T10:47:22.4140434+09:00
imports:
- name: github.com/spiegel-im-spiegel/astrocalc
  version: 256cd3bd4dc63441d3f4759d761593a147d51d88
  subpackages:
  - modjulian
devImports: []

glide.lock があれば glide install（または glide i）コマンドで vendor フォルダ以下の状態を復元できる。

glide では外部パッケージを vendor フォルダ以下に repository 構造ごと展開する。この場合，開発対象のパッケージも repository で管理しているのだから， repository が入れ子になり具合が悪い。その辺，当の glide はどうしてるのかなぁと思ったら .gitignore ファイルで vendor/ を除外対象にしていた。なるほど，そりゃそうか。

glide.yaml および glide.lock ファイルの管理さえちゃんとしていれば glide install コマンドでいつでも復元できるのだから vendor フォルダ以下を除外しても問題ないわけだ⁵。これは複数メンバで開発環境を共有する際には便利な機能である。

また vendoring に対応していない（Go 1.4 以下の）環境や glide がない環境では go get で外部パッケージを取ってくることで（revision 等の問題はあるけど）一応ビルドは通る。

更に言うと， glide は Go 言語の標準機能に準拠しているため，他のサポートツールとの相性がいいのも利点だろう。たとえば， ATOM ベースの開発環境は glide と相性がいい⁶。あと，（多少強引な手を使っているが⁷） Travis CI のような CI (Continuous Integration) と組み合わせることも難しくない。

こう考えると glide は前に紹介した gb よりも筋がいいツールといえるかもしれない。

おまけ： vender フォルダ以下をテストから除外する

テストを行う際に普通に

$ go test -v ./...

とかやると vendor フォルダ以下も対象になってしまう。 vendor フォルダ以下を除外したいのであれば

$ go test -v $(glide novendor)

とすればよい。

ただこれ Windows のコマンドプロンプトでは使えないんだよねぇ。パイプで go test に渡してもうまくいかない感じ。そういう場合は glide novendor の実行結果を整形してバッチファイルにするしかないのだろう。やれやれ。

ブックマーク

Go 言語に関するブックマーク集はこちら。

Mac 環境なら brew でインストールできるらしい。 Linux 等の環境であれば make コマンドで各種プラットフォームの実行ファイルをビルドできる。一応 go get でもビルドできるが， revision を制御できないので失敗する可能性もある（これは make コマンドでビルドする場合でも同じだけど）。 ↩︎
glide create 時の依存パッケージの推測を抑止するには --skip-import オプションを付ける。のだが，効いてないな。 ↩︎
今回であれば repository の v0.1.0 タグに対応する revision を選択する。バージョンの記述形式は package.json と同じように記述でき，バージョンの解釈は Semantic Versioning に従っている。ちなみに revision ID を直接指定することもできる。 ↩︎
glide では git のほか svn (Subversion), hg (Mercurial), bzr (Bazaar) が利用可能である。 ↩︎
vendor フォルダ以下は外部パッケージなので通常はさわることはない。 ↩︎
残念ながら，「パッケージの依存状況の視覚化」ツールは vendoring 機能に対応していないため上手く表示できない。なお， glide では glide list および glide tree で依存パッケージを見ることができる。 ↩︎
glide の .travis.yml や Makefile を参照。 ↩︎

GOPATH 汚染問題

2015-09-29T14:40:59+00:00

【注意 2018-09-26】 この問題はバージョン 1.11 からサポートされる「モジュール」機能によって解消可能です。もはやこの記事の内容は古いものであり「こんな時代もあったね」と生暖かい気持ちで読んでいただければ幸いです。

（初出：そろそろ真面目に Golang 開発環境について考える — GOPATH 汚染問題 - Qiita，そろそろ真面目に Golang 開発環境について考える — Internal Packages と Vendoring - Qiita）

go get コマンドはとても強力な機能で，私のように Windows と UNIX 系環境の間を渡り歩いてる身としては， make などの tool chain に大きく依存することなく， go get コマンドだけで repository の fetch からビルド・インストールまで出来てしまうのは非常にありがたい¹。

しかし， go get コマンドは外部パッケージの revision 等をコントロールできず，常に repository の最新コードを取ってこようとする。ひとつの環境でひとつのプロジェクトを管理していくのならこれでも何とかならないこともないが， GOPATH 内に複数のプロジェクトが同居している場合は同じ外部パッケージでもプロジェクトごとに異なるリビジョンを要求する可能性があり，管理が煩雑になってしまう。

しかも困ったことに GOPATH 環境変数は複数のプロジェクト管理を想定していないため，全てのパッケージをひとつのフォルダに入れようとする² ³。

【対策1】プロジェクトごとに GOPATH を設定し直す

この問題に対する一番安直な答えは「プロジェクトごとに GOPATH を設定し直す」である。例えば前回紹介した gb をビルドする場合は以下のようにする。

C:>mkdir C:\workspace\gb

C:>SET GOPATH=C:\workspace\gb

C:>go get -v github.com/constabulary/gb/...
github.com/constabulary/gb (download)
github.com/constabulary/gb/log
github.com/constabulary/gb
github.com/constabulary/gb/vendor
github.com/constabulary/gb/cmd
github.com/constabulary/gb/cmd/gb
github.com/constabulary/gb/cmd/gb-vendor

あとは GOPATH 直下の bin フォルダにパスを通すか，パスの通ってるフォルダに実行ファイルをコピーすればよい。実行履歴はバッチファイル（UNIX 系なら shell スクリプト）に保存しておけばいつでも復元できる。

毎回環境をセットアップしないといけないのは面倒だが，プロジェクト管理のためのツールも必要なく， Go コンパイラの標準機能のみで管理できる。標準機能のみで管理できるというのは結構重要で，たとえば CI ツールを使っている場合は，設定を単純にできるので管理しやすいといえる。

UNIX 系の環境であれば direnv を使う手もある⁴。 direnv は cd をフックし，ディレクトリごとに環境変数を書き換えることができる。この機能を使ってプロジェクト・フォルダごとに GOPATH を設定できる。

【対策2】プロジェクト・ベースの管理ツールを使う

もうひとつは gb のようなプロジェクト・ベースでコード管理のできるツールを使う方法である。 gb については前回紹介したので，そちらを参照のこと。

gb で作った開発環境はフォルダ構成を丸ごと開発メンバに配布・同期することが可能になるため，複数人で環境を合わせることが容易になる。

【対策3】 Go 1.5 の Vendoring 機能を使う

Go 言語のバージョン 1.5 から Vendoring 機能が使えるようになった。

Vendoring 機能を使うと，外部パッケージを GOPATH とは独立に管理できるようになる。この機能を使うには環境変数 GO15VENDOREXPERIMENT に 1 をセットする。

（追記当初の予告通り Vendoring 機能は 1.6 から既定の機能になった。環境変数 GO15VENDOREXPERIMENT をセットしなくても有効になる）

Go 1.5 Vendor Experiment

Vendoring 機能が有効な状態では vendor フォルダが特別な意味を持つ。たとえば mypackage パッケージに対して mypackage/vendor/vpackage と配置した場合， import "vpackage" と記述すれば mypackage/vendor フォルダ以下の vpackage も探してくれる。

では，前回作ったコードを流用して確かめてみる。

C:\workspace\vdemo>SET GOPATH=C:\workspace\vdemo

C:\workspace\vdemo>SET GO15VENDOREXPERIMENT=1

C:\workspace\vdemo>tree /f .
C:\WORKSPACE\VDEMO
└─src
    └─julian-day
            julian-day.go

C:\workspace\vdemo>go build ./...
src\julian-day\julian-day.go:10:2: cannot find package "github.com/spiegel-im-spiegel/astrocalc/modjulian" in any of:
        C:\Go\src\github.com\spiegel-im-spiegel\astrocalc\modjulian (from $GOROOT)
        C:\workspace\vdemo\src\github.com\spiegel-im-spiegel\astrocalc\modjulian (from $GOPATH)

C:\workspace\vdemo>mkdir src\julian-day\vendor

C:\workspace\vdemo>tree /f .
C:\WORKSPACE\VDEMO
└─src
    └─julian-day
        │  julian-day.go
        │
        └─vendor


C:\workspace\vdemo>go build ./...
src\julian-day\julian-day.go:10:2: cannot find package "github.com/spiegel-im-spiegel/astrocalc/modjulian" in any of:
        C:\workspace\vdemo\src\julian-day\vendor\github.com\spiegel-im-spiegel\astrocalc\modjulian (vendor tree)
        C:\Go\src\github.com\spiegel-im-spiegel\astrocalc\modjulian (from $GOROOT)
        C:\workspace\vdemo\src\github.com\spiegel-im-spiegel\astrocalc\modjulian (from $GOPATH)

vendor フォルダを追加したことで Go コンパイラの挙動が変わったことがお分かりだろうか。目的のパッケージを vendor tree → GOROOT → GOPATH の順で捜索している。

では vendor フォルダに外部パッケージを導入してビルドしてみよう。

C:\workspace\vdemo>pushd src\julian-day\vendor

C:\workspace\vdemo\src\julian-day\vendor>git clone https://github.com/spiegel-im-spiegel/astrocalc.git github.com/spiegel-im-spiegel/astrocalc
Cloning into 'github.com/spiegel-im-spiegel/astrocalc'...
remote: Counting objects: 43, done.
remote: Total 43 (delta 0), reused 0 (delta 0), pack-reused 43
Unpacking objects: 100% (43/43), done.
Checking connectivity... done.

C:\workspace\vdemo\src\julian-day\vendor>popd

C:\workspace\vdemo>tree /f .
C:\WORKSPACE\VDEMO
└─src
    └─julian-day
        │  julian-day.go
        │
        └─vendor
            └─github.com
                └─spiegel-im-spiegel
                    └─astrocalc
                        │  .editorconfig
                        │  .gitignore
                        │  .travis.yml
                        │  LICENSE
                        │  README.md
                        │
                        └─modjulian
                                example_test.go
                                LICENSE
                                modjulian.go
                                modjulian_test.go

C:\workspace\vdemo>go install -v ./...
julian-day/vendor/github.com/spiegel-im-spiegel/astrocalc/modjulian
julian-day

C:\workspace\vdemo>tree /f .
C:\WORKSPACE\VDEMO
├─bin
│      julian-day.exe
│
├─pkg
│  └─windows_amd64
│      └─julian-day
│          └─vendor
│              └─github.com
│                  └─spiegel-im-spiegel
│                      └─astrocalc
│                              modjulian.a
│
└─src
    └─julian-day
        │  julian-day.go
        │
        └─vendor
            └─github.com
                └─spiegel-im-spiegel
                    └─astrocalc
                        │  .editorconfig
                        │  .gitignore
                        │  .travis.yml
                        │  LICENSE
                        │  README.md
                        │
                        └─modjulian
                                example_test.go
                                LICENSE
                                modjulian.go
                                modjulian_test.go

C:\workspace\vdemo>bin\julian-day.exe 2015 1 1
2015-01-01 00:00:00 +0000 UTC
MJD = 57023日

vendor フォルダ以下にパッケージがフルパスで入ってしまうため階層が深くなりがちなのが「玉に瑕」だが，それ以外は特に問題はない。あるいは vendor フォルダ以下のパッケージは go get の制約から外れているので，呼び出し側を

import (
    "flag"
    "fmt"
    "os"
    "strconv"
    "time"

    "astrocalc/modjulian"
)

として以下のフォルダ構成にする手もある⁵。

C:\workspace\vdemo>tree /f .
C:\WORKSPACE\VDEMO
└─src
    └─julian-day
        │  julian-day.go
        │
        └─vendor
            └─astrocalc
                │  .editorconfig
                │  .gitignore
                │  .travis.yml
                │  LICENSE
                │  README.md
                │
                └─modjulian
                        example_test.go
                        LICENSE
                        modjulian.go
                        modjulian_test.go


C:\workspace\vdemo>go install -v ./...
julian-day/vendor/astrocalc/modjulian
julian-day

C:\workspace\vdemo>bin\julian-day.exe 2015 1 1
2015-01-01 00:00:00 +0000 UTC
MJD = 57023日

注意が必要なのは， go get は git の submodule を上手く扱えないため， vendor フォルダ以下のパッケージを submodule として配置している場合はビルドに失敗することだ。この場合は -d オプションで go get がビルドまで行わないようにし，手動で submodule の init と update を行う必要がある。

C:>go get -d project/...
C:>git submodule init
C:>git submodule update
C:>go install ./...

（「Glide で Vendoring」に続く）

ブックマーク

それでも git などのコード管理ツールへの依存はどうしても残るのだけれど。 ↩︎
具体的には GOPATH で列挙されるパスのリストのうち先頭のパスにインストールされる。 ↩︎
Go 言語の開発・管理主体は Google だが，こんな構成で Google は困らないのかと思ったのだが，実は Google は全てのコードを単一の repository で管理しているらしい。（参考： 20億行のコードを保存し、毎日4万5000回のコミットを発行しているGoogleが、単一のリポジトリで全社のソースコードを管理している理由） ↩︎
direnv は Go 言語で組まれている。 ↩︎
パッケージのパスが変わるとテストが通らなくなる場合があるので注意。 ↩︎

List of Vendoring [text.Baldanders.info]

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

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

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

ブックマーク

参考図書

Go 言語の依存性管理ツール Dep v0.4 がリリースされていた

ブックマーク

Glide から Dep への移行を検討する

dep の取得

glide から dep への移行

依存関係の管理

依存関係の視覚化

リポジトリへのパスを直接指定する

Go 1.9 から glide novendor は必要なくなった

ブックマーク

Glide で Vendoring

Glide のインストール

開発環境の準備

依存関係を定義する

パッケージの取得とビルド

Vendor フォルダの管理

おまけ： vender フォルダ以下をテストから除外する

ブックマーク

GOPATH 汚染問題

【対策1】 プロジェクトごとに GOPATH を設定し直す

【対策2】 プロジェクト・ベースの管理ツールを使う

【対策3】 Go 1.5 の Vendoring 機能を使う

ブックマーク

【対策1】プロジェクトごとに GOPATH を設定し直す

【対策2】プロジェクト・ベースの管理ツールを使う