cmd/go: 'go mod vendor' removes requirement on replaced module

[songjiayang]

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

$ go version
go version go1.12 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/xxxx/Library/Caches/go-build"

GOEXE=""

GOFLAGS=""

GOHOSTARCH="amd64"

GOHOSTOS="darwin"

GOOS="darwin"

GOPATH=""

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="/project/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/zb/p5mbxpss5j19k76c9kd3wy5jxfrpjg/T/go-build045757485=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I run go mod vendor to package all my code dependence, the go.mod had been changed.

Before change:

module my-module

require (
	my.module.com/common/appconfig v0.0.0
	my.module.com/common/config v0.0.0
)

replace (
	my.module.com/common/appconfig => ../common/appconfig
	my.module.com/common/config => ../common/config
)

After change:

module my-module

require (
	my.module.com/common/appconfig v0.0.0
)

replace (
	my.module.com/common/appconfig => ../common/appconfig
	my.module.com/common/config => ../common/config
)

It auto delete my.module.com/config at require field, then i build with -mod=vendor , Go 1.12 is ok , but Go 1.11.2 with error cannot find module for path my.module.com/common/config exit 1

In this case, my appconfig module had required config yet, So I want to known this's a bug for Go 1.12 or a new feature.

[songjiayang]

@bcmills so , it's Go1.2 modules bug?

[songjiayang]

I test Go from v1.11.2 to v1.12.1. I find all of them will remove requirements from go.mod when run go mod vendor, and only Go1.12.x can normal run with -mod=vendor, Go1.11.x raise error: cannot find module for path my.module.com/common/config exit.

I don't display import my.module.com/common/config in my project, so removed from go.mod can , but I think Go 1.11.x should works like Go1.12.x，run -mod=vendor without error.

[songjiayang]

I test Go from v1.11.2 to v1.12.1. I find all of them will remove requirements from go.mod when run go mod vendor, and only Go1.12.x can normal run with -mod=vendor, Go1.11.x raise error: cannot find module for path my.module.com/common/config exit.

I don't display import my.module.com/common/config in my project, so removed from go.mod can , but I think Go 1.11.x should works like Go1.12.x，run -mod=vendor without error.

run without -mod=vendor using Go 1.11.x, it's ok. So it's a bug about -mod=vendor

[bcmills]

In general the interaction between go mod tidy, go mod vendor, and replace directives is a bit awkward (see also #29182 and #29181). I wouldn't be at all surprised if something about go mod vendor interacts badly with replacements.

As for the build succeeding with Go 1.12 only, that's probably due to the fix for #27859 or #26241.

[bcmills]

@songjiayang, ideally it would be helpful to see the source code for the module that reproduces this error. In particular:

• Do any packages in my-module import from the config module?
• Do any packages in the original and/or replaced appconfig import from the config module?
• Does the go.mod file for the replaced appconfig module specify a version for the config module?

The output of go mod graph and go mod why -m my.module.com/common/config would be particularly helpful.

CC @jayconrod

[songjiayang]

@bcmills @jayconrod There is a example about the details, you can check it with link https://github.com/songjiayang/go-module-bug-example please.

[bcmills]

Thanks for the concrete example.

As far as I can tell, the underlying bug was completely fixed in Go 1.12: the require go.mod/a v0.0.0 line is removed because it is implied by require go.mod/b v0.0.0, which specifies its own requirement on the same version of a.

I suspect that the failure you were seeing with Go 1.11 was due to #27859.