cmd/go: list command modifies the go.mod file

[nd]

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

$ go version
go version go1.13.1 linux/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="/home/nd/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/nd/go"
GOPROXY=""
GORACE=""
GOROOT="/home/nd/go/go1.12.9"
GOTMPDIR=""
GOTOOLDIR="/home/nd/go/go1.12.9/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/nd/tmp/sonja/src/github.com/sirupsen/logrus/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-build584675799=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Executed the go list -m -json all command in github.com/sirupsen/logrus and https://github.com/go-yaml/yaml/ repositories

What did you expect to see?

List of modules + unmodified go.mod files.

What did you see instead?

The go.mod files were modified, the go 1.13 line was added in logrus and in the go-yaml

module "gopkg.in/yaml.v3"

require (
	"gopkg.in/check.v1" v0.0.0-20161208181325-20d25e280405
)

was changed to

module gopkg.in/yaml.v2

require gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405

go 1.13

The go list documentation doesn't mention that it changes go.mod files, imo it should not.

[mvdan]

/cc @bcmills

[bcmills]

Duplicate of #34822

[bcmills]

Wait, no. In this case there is a non-cosmetic change: the addition of the go directive.

[bcmills]

This is working as designed and documented. Per https://golang.org/cmd/go/#hdr-Maintaining_module_requirements:

The go command itself automatically updates the go.mod file to maintain a standard formatting and the accuracy of require statements.

[…]

Because of this automatic maintenance, the information in go.mod is an up-to-date, readable description of the build.

[nd]

The problem with such an approach is when the command is executed by tools, not the user. E.g. an editor or CI build can retrieve dependencies information using go list and it is unexpected that this will change go.mod files (there was no such effect in go 1.12). Would it be possible to add an addition mode similar to -mod=readonly but instead of failing skip updating go.mod? Or maybe there are other workarounds?

[bcmills]

@nd, tools that do not intend to update the go.mod file should set -mod=readonly, in which case the second part of #34822 applies (and see also #34829).

[nd]

Do I understand correctly that missing go version will be added anyway after fix for #34822?

[bcmills]

Yes, the go version is important for reproducibility — it isn't just cosmetic.

[matschaffer]

Incase it helps any intellij users dealing with multiple golang versions in the same project: I've been trying https://intellij-support.jetbrains.com/hc/en-us/community/posts/360006485599-automatically-insert-system-s-go-version-in-go-mod-?page=1#community_comment_360001297500 as a workaround and it seems okay.

Would be nice if either intellij had a way to specify a per-module golang sdk, or if go list had an option to not try to write go.mod regardless of cosmetic/not.

But will keep searching for something to fill the gap as neatly as possible.

[drornir]

Yes, the go version is important for reproducibility — it isn't just cosmetic.

This is weird. How come I have no control over go list modifying my go.mod?
I understand that this is "intended", but there is no explaination here.