Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
nd opened this issue Oct 11, 2019 · 10 comments
Closed

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

nd opened this issue Oct 11, 2019 · 10 comments
Labels
FrozenDueToAge modules

Comments

@nd
Copy link
Contributor

nd commented Oct 11, 2019

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 mvdan added the modules label Oct 11, 2019
@mvdan
Copy link
Member

mvdan commented Oct 11, 2019

/cc @bcmills

@mvdan mvdan changed the title go list command modifies the go.mod file cmd/go: list command modifies the go.mod file Oct 11, 2019
@bcmills
Copy link
Contributor

bcmills commented Oct 11, 2019

Duplicate of #34822

@bcmills bcmills marked this as a duplicate of #34822 Oct 11, 2019
@bcmills bcmills closed this as completed Oct 11, 2019
@bcmills
Copy link
Contributor

bcmills commented Oct 11, 2019

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

@bcmills bcmills reopened this Oct 11, 2019
@bcmills
Copy link
Contributor

bcmills commented Oct 11, 2019

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.

@bcmills bcmills closed this as completed Oct 11, 2019
@nd
Copy link
Contributor Author

nd commented Oct 11, 2019

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
Copy link
Contributor

bcmills commented Oct 11, 2019 •
edited

@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
Copy link
Contributor Author

nd commented Oct 11, 2019

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

@bcmills
Copy link
Contributor

bcmills commented Oct 11, 2019

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

@ridersofrohan ridersofrohan mentioned this issue Dec 23, 2019
Closed
@matschaffer
Copy link

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
Copy link

drornir commented May 4, 2020

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.

@golang golang locked and limited conversation to collaborators May 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@matschaffer @nd @mvdan @bcmills @gopherbot @drornir