現象
例えば素朴にGithubから何らかのinternalパッケージを使用しているGoプロジェクトをCloneする。
それも適当なディレクトリに。
aya-eiya> cd ~/work/go
aya-eiya> git clone https://github.com/peco/peco
aya-eiya> cd peco
aya-eiya> make installdeps # <- この時点でワーニングが割りと出る
aya-eiya> make test
ビルドエラーとして以下が得られる。
cmd/peco/peco.go:9:2: use of internal package not allowed
・
・
・
対処
GOPATHを例えば以下に設定する。
export GOPATH=~/work/home/go
プロジェクトを以下に移動する。
aya-eiya> cd ~/work/go
aya-eiya> mkdir -p src/github.com/peco
aya-eiya> mv peco/ src/github.com/peco/
aya-eiya> cd src/github.com/peco/peco
aya-eiya> make clean installdeps test
# Greenダヨ！
なんで？
internal packageについて
Goには、プロジェクト内からのアクセスのみを許可する参照スコープを定義する目的で、internalパッケージという機能がVersion 1.4から用意されています。
internalという名前でパッケージの階層を作ると、そのinternalの下のSymbolはそのinternalを置いたパッケージと同階層のパッケージからしか参照できなくなります。
公開されるGo Projectのimport記法
公開することを見越したGo Projectでは、importに公開した時にそうなるだろうパッケージ名を付けてシンボルを設定しているようです。
例えば、例としてあげたPecoのコードであれば、importは以下のように設定されています。
import (
"fmt"
"os"
"runtime"
"github.com/peco/peco"
"github.com/peco/peco/internal/util" // <- インターナルなのぜ
"context"
)
なので、ローカルでビルドする場合でも、クローンしたプロジェクトが、GOPATHからgithub.com/pecoに置かれているように見えなければなりません。