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/foo
from go 1.12 (works) vs 1.13 (errors).example.com/foo
is 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/load
assume (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/hpack
from withinGOPATH
, and resolve it to the pathvendor/golang.org/x/net/http2/hpack
with locationGOPATH/src/vendor/golang.org/x/net/http2/hpack
. 2 Then we loadnet/http
from 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
GOPATH
andGOROOT
swapped.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
GOPATH
mode (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
vendor
subdirectory to a second completeGOPATH
entry.So you might do something like:
Then you can keep building in
GOPATH
mode without the top-levelsrc/vendor
directory.(That said, at this point I would strongly encourage you to migrate to module mode, and then the semantics of
GOPATH/vendor
are moot.)