cmd/go: allow 'go mod vendor' to omit replaced modules

[mkeeler]

What version of Go are you using (go version)?

$ go version
go version go1.12.9 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/mkeeler/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/mkeeler/.go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/mkeeler/Code/repos/consul/master/go.mod"
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/dc/5dk846911dbdkmjk4bj47hhm0000gn/T/go-build297831786=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

1. git clone https://github.com/hashicorp/consul
2. go mod vendor

What did you expect to see?

I didn't expect vendor/modules.txt to contain the nested modules within it nor having those nested modules be vendored into the top level vendor folder.

What did you see instead?

Nested submodules are vendored.

We currently get around this by postprocessing the modules.txt and the vendor directory. I realize that nested modules might not be a great idea (it has caused me a number of headaches) however for code living in the same repo the current go mod vendor behavior of vendoring our own code doesn't make much sense to me. Is this intended behavior or just something that isn't protected against.

[bcmills]

Is this intended behavior or just something that isn't protected against.

At the moment, this is working as designed: go mod vendor doesn't know (or particularly care) about the overall repo structure — it just knows where the main module is and vendors in the dependencies of the main module wherever they are found.

Omitting same-repo dependencies is one of the use-cases I had in mind for partial vendoring (#30240).

[carter2000]

@bcmills Any plans for partial vendoring ?

[bcmills]

This issue is milestoned to Backlog. So not at the moment, no.

[shoenig]

@bcmills is this something ya'll plan to work on? Is it something we can contribute a PR for? This is a sharp edge that burdens us daily.

[bcmills]

@shoenig, we don't have any specific plans to work on this. If this feature is important to you, some more detail on your use-case (especially the alternatives you considered and the problems with those alternatives) would be helpful.

At the moment, the big question is whether the added convenience is worth the added complexity (of both the implementation and the documentation).

[snluu]

@bcmills Thanks for your responses.

The main issue I'm running into with my use-case is where I have local dependencies. Currently, the way that I'm import local dependency is via using replace mydomain.com/mypackage => ../mypackage.

However, this does not work with vendoring, because vendoring would copy ../mypackage to ./vendor/mydomain.com/mypackage.