go: cmd/go: emit an explicit error when packages in GOPATH/src/vendor overlap with GOROOT/src/vendor
What version of Go are you using (go version)?
$ go version go version go1.13 darwin/amd64
Does this issue reproduce with the latest release?
only in go1.13 happened, back to go1.12.9 can fix this
What operating system and processor architecture are you using (go env)?
go env Output
$ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/Users/username/Library/Caches/go-build" GOENV="/Users/username/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/b1/bhf9j3q96m75223l3hh41ccw0000gn/T/go-build173249759=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
go install -v ./…
What did you expect to see?
no errrors
What did you see instead?
src/vendor/golang.org/x/net/http2/frame.go:17:2: use of vendored package not allowed src/vendor/google.golang.org/grpc/internal/transport/controlbuf.go:28:2: use of vendored package not allowed src/vendor/golang.org/x/net/http2/transport.go:35:2: use of vendored package not allowed
About this issue
- Original URL
- State: open
- Created 5 years ago
- Reactions: 5
- Comments: 21 (19 by maintainers)
Commits related to this issue
- cri-o: workaround failure since go upgraded to 1.13 Source: meta-virtualization MR: 00000 Type: Integration Disposition: Merged from meta-virtualization ChangeID: 00cc8afd1e80e73f1205691c4ce440498b52... — committed to MontaVista-OpenSourceTechnology/meta-virtualization by hongxu-jia 5 years ago
- cri-o: workaround failure since go upgraded to 1.13 Since go was upgraded to 1.13, there is a failure: ... | src/vendor/golang.org/x/net/http2/frame.go:17:2: use of vendored package not allowed | ../... — committed to lgirdk/meta-virtualization by hongxu-jia 5 years ago
I think I ran into the same issue. I made an example repo here to demonstrate the issue: https://github.com/psanford/gobug34068
If you checkout that repo and set your GOPATH to the git working directory you can try building package
example.com/foofrom go 1.12 (works) vs 1.13 (errors).example.com/foois a grpc client hello world example.Grpc and its dependencies were vendored in src/vendor via gvt.
Found a much smaller reproducer.
I looked into this today, but I’m not sure that it’s feasible to fix.
The trouble is that a number of caches within
cmd/go/internal/loadassume (and have long assumed) that every package has a unique canonical import path, and import paths whose first component does not contain a dot are in general reserved for the standard library.The simple failure mode is this:
golang.org/x/net/http2/hpackfrom withinGOPATH, and resolve it to the pathvendor/golang.org/x/net/http2/hpackwith locationGOPATH/src/vendor/golang.org/x/net/http2/hpack. 2 Then we loadnet/httpfrom withinGOROOT, and we also resolve it tovendor/golang.org/x/net/http2/hpack. The cache shows the location of that package to beGOPATH/src/vendor/golang.org/x/net/http2/hpack, but if we loaded it from scratch we would have gottenGOROOT/src/vendor/golang.org/x/net/http2/hpack.A similar failure mode occurs with the relative ordering of
GOPATHandGOROOTswapped.A long-term fix would be to have all of the caches track packages by directory instead of import path. That change is fairly invasive, and in general we are not pursuing long-term fixes in
GOPATHmode (although we do try to avoid regressions).@bronze1man, it occurs to me that there is one more possible workaround in GOPATH mode: namely, you can promote the top-level
vendorsubdirectory to a second completeGOPATHentry.So you might do something like:
Then you can keep building in
GOPATHmode without the top-levelsrc/vendordirectory.(That said, at this point I would strongly encourage you to migrate to module mode, and then the semantics of
GOPATH/vendorare moot.)