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

Most upvoted comments

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.

-- issue34068/issue34068.go --
package issue34068

import (
	_ "net/http"
	_ "golang.org/x/net/http2/hpack"
)
-- $GOPATH/src/vendor/golang.org/x/net/http2/hpack/hpack.go --
package hpack

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:

  1. First we load golang.org/x/net/http2/hpack from within GOPATH, and resolve it to the path vendor/golang.org/x/net/http2/hpack with location GOPATH/src/vendor/golang.org/x/net/http2/hpack. 2 Then we load net/http from within GOROOT, and we also resolve it to vendor/golang.org/x/net/http2/hpack. The cache shows the location of that package to be GOPATH/src/vendor/golang.org/x/net/http2/hpack, but if we loaded it from scratch we would have gotten GOROOT/src/vendor/golang.org/x/net/http2/hpack.

A similar failure mode occurs with the relative ordering of GOPATH and GOROOT 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 complete GOPATH entry.

So you might do something like:

$ mkdir govendor
$ mv $GOPATH/src/vendor govendor/src
$ export GOPATH=$GOPATH:$(pwd)/govendor

Then you can keep building in GOPATH mode without the top-level src/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.)