cmd/go: go adds unnecessary module dependency

[alanconway]

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

go version go1.12.9 linux/amd64

Does this issue reproduce with the latest release?

Don't know, using latest packaged release on Fedora.

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

go env Output

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/aconway/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/aconway/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/golang"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/aconway/gomod/src/github.com/cloudevents/sdk-go/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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build160743641=/tmp/go-build -gno-record-gcc-switches"

What did you do?

$ git clone https://github.com/cloudevents/sdk-go
$ cd sdk-go
$ go list -m
github.com/cloudevents/sdk-go
$ go mod tidy
$ grep gogo go.mod # Note output is empty
$ go list -m
github.com/cloudevents/sdk-go
$ grep gogo go.mod # Just `go list -m` causes this dep to appear.
	github.com/gogo/protobuf v1.2.0 // indirect
$ go mod why github.com/gogo/protobuf
# github.com/gogo/protobuf
(main module does not need package github.com/gogo/protobuf)
$ go mod tidy
$ grep gogo go.mod # gogo is gone again!
$ 

What did you expect to see?

No incorrect dependencies in go.mod.
Agreement between go tools on what dependencies are required.
After a successful go build; go mod tidy, subsequent calls of go build or
go mod tidy with no code changes should not change go.mod.

What did you see instead?

Calling go list -m or any go comand (go build etc.) adds a line to go.mod

	github.com/gogo/protobuf v1.2.0 // indirect

Calling go tidy removes that line.

I suspect this may be some environmental factor on my machine as I haven't heard anyone else with this problem but I don't know what it might be.

[zikaeroh]

Given you're still on 1.12, this is probably #31248, fixed in 1.13.

[n3wscott]

/watch

[thepudds]

@alanconway As @zikaeroh mentioned, there were fixes in this area for Go 1.13. If you run through these steps with Go 1.13, does the problem still happen?

[alanconway]

Still happens on 1.13, I uninstalled the 1.12 installation to ensure I wasn't picking up any old libs.

My symptoms are different from #31248 - go tidy is behaving correctly, it is removing a package that is not needed. go why agrees that it is not needed. However go list, go build and other commands add it back. I built github.com/cloudevents/sdk-go with go dep in GOPATH mode to confirm that github.com/gogo/protobuf is really not required to build.

[douglarek]

I got the same issue as @alanconway and I use go 1.13

[bcmills]

@alanconway, I'm unable to reproduce the behavior you observed using go1.13.1. Can you provide a specific commit of the repository that I can check out to reproduce the behavior?

This may be a duplicate of #34086, but without a current reproducer it's hard to be sure.

[alanconway]

@bcmills 1.13.1 works for me, looks like it's fixed :) Thanks.

[douglarek]

Some supplement for this: it only works when you use go 1.13.1 and also use 1.13.1 in go.mod file.

And another question: when using a newer go version, should go.mod's go version be updated automatically @bcmills , thanks!

[bcmills]

it only works when you use go 1.13.1 and also use 1.13.1 in go.mod file.

The go.mod file specifies only the language version: go 1.13.1 in the go.mod file should not be accepted in the first place. (go 1.13, however, should.)

And another question: when using a newer go version, should go.mod's go version be updated automatically

No. Newer versions of the toolchain can compile older versions of the language spec, so in general it should not be necessary to update the go directive unless you need to enable newer language features.

[bcmills]

@douglarek, the problem originally reported here does not seem to reproduce, so I'm going to close this issue.

If you're seeing something you believe to be a bug, please file a new issue with concrete steps to reproduce it — ideally, a repo that we can check out at a specific commit to demonstrate the problem.