cmd/go: warn when go get removes a module that provides a package in the import graph?

[onokonem]

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

go version go1.11.4 darwin/amd64

Does this issue reproduce with the latest release?

yes it does

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

go env Output

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/U/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/U/Work/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/U/Work/TestProj/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/rm/sngdtnn11x3b_zp_zzyw6jl40000gn/T/go-build528112071=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

$go get github.com/miekg/dns/idn@cdb76b64a347436f019bf96ab5eb2d74e73e964b
go: finding github.com/miekg/dns/idn cdb76b64a347436f019bf96ab5eb2d74e73e964b
$grep dns go.mod
 github.com/miekg/dns v0.0.0-20171124081448-cdb76b64a347
$go mod vendor
go: finding github.com/miekg/dns/idn latest
$grep dns go.mod
 github.com/miekg/dns v1.1.1

What did you expect to see?

github.com/miekg/dns v0.0.0-20171124081448-cdb76b64a347 vendored

What did you see instead?

github.com/miekg/dns v1.1.1 vendored

[bcmills]

You've left something out: there are no dependencies to vendor. Please provide a complete set of steps we can follow to reproduce the issue.

It is possible that the requirement is coming in via some other dependency that was previously missing from your go.mod file. (If so, go mod graph should be able to tell you where it comes from.)

scratch$ go1.12beta2 mod init golang.org/issue/scratch
go: creating new go.mod: module golang.org/issue/scratch

scratch$ go1.12beta2 get github.com/miekg/dns/idn@cdb76b64a34
go: finding github.com/miekg/dns/idn cdb76b64a34
go: finding github.com/miekg/dns cdb76b64a34
go: downloading github.com/miekg/dns v0.0.0-20171124081448-cdb76b64a347
go: extracting github.com/miekg/dns v0.0.0-20171124081448-cdb76b64a347

scratch$ cat go.mod
module golang.org/issue/scratch

go 1.12

require github.com/miekg/dns v0.0.0-20171124081448-cdb76b64a347 // indirect

scratch$ go1.12beta2 mod vendor
go: no dependencies to vendor

[onokonem]

unfortunately I can not recreate the problem on the minimal project.

on the project I have this problem I can see
go get github.com/miekg/dns/idn@cdb76b64a347436f019bf96ab5eb2d74e73e964b
does NOT update vendor/modules.txt file (it DOES on the minimal one)

and go mod vendor updates the go.mod file on the big project

hope this helps

[bcmills]

go get […] does NOT update vendor/modules.txt file

go get itself is not intended to update vendor at all. (That feature request is #29058.)

[bcmills]

and go mod vendor updates the go.mod file on the big project

That seems to confirm the hypothesis that there is some transitive dependency that imposes a higher minimum version.

In the larger repo, try (in order):

1. go get github.com/miekg/dns/idn@cdb76b64a347436f019bf96ab5eb2d74e73e964b
2. go mod graph | grep github.com/miekg/dns
3. go mod tidy
4. go list -m github.com/miekg/dns
5. go mod graph | grep github.com/miekg/dns
6. go mod vendor
7. go list -m github.com/miekg/dns

If the version is through a transitive dependency that cannot be downgraded, then that dependency will not be listed in step (2), and the version will bump back up again at step (4) and remain stable thereafter.

[onokonem]

yeah, this is the source of my problem: https://github.com/influxdata/platform/blob/master/go.mod#L99. thank you very much for your help.

do you think it might be useful to have a warning message in this case?

go get itself is not intended to update vendor at all

but it does update vendor/modules.txt with the minimal project

[bcmills]

do you think it might be useful to have a warning message in this case?

I'm not sure, but it's certainly worth considering. I'll retitle the issue accordingly.

[matloob]

We don't plan to do this. Closing the issue. Please reopen if it's still a problem.