cmd/go: do not update 'go.mod' automatically if the changes are only cosmetic

[bcmills]

#29452, #33779, and #31870 all describe issues due to cosmetic changes in the go.mod file (specifically, newlines). CL 186557 changed the go command to properly omit versions already implied by the module graph.

It is possible that future changes to the go command will similarly add or remove redundant or non-essential information from the go.mod file. (For example, #25898 (comment) suggests adding a comment for pseudo-versions indicating the corresponding non-semver tag, if any.)

It is annoying and sometimes intrusive for the go command to make unnecessary edits to the go.mod file.

go mod tidy should apply cosmetic edits to tidy up the file: that is part of its purpose. However, for other commands, I suggest:

• The go command should not overwrite the go.mod file if it contains only formatting changes (spacing, newlines, ordering, grouping, etc.) or removes redundant-but-not-misleading information (such as a require line that specifies an indirect dependency already implied by some other indirect dependency).

• If -mod=readonly is set, the go command should not fail if the go.mod file contains additional comment-only changes (such as the addition or removal of an // indirect comment), or omits helpful-but-unnecessary information (such as a require line for a direct dependency whose version is already implied by an indirect one, but contrast cmd/go: update to '@latest' when promoting an indirect dependency to a direct one? #34534).

CC @jayconrod

[dmitshur]

Would it be a reasonable analogy to say this is like running the go build command on poorly formatted Go code. The go build command successfully builds such code but does not automatically apply formatting changes to it. One needs to use gofmt (or equivalent) separately to format Go code.

[bcmills]

Yes, except that the go command (unlike the compiler) does automatically update the go.mod file as needed to get things to build.

[nd]

The analogy above doesn't work: compiler doesn't change the code in case of compilation errors even if they are obvious; go build doesn't reformat the code: one has to run a dedicated command for that explicitly.

IMHO it is hard to integrate with tools behaving like this. Every client will have to check and handle go.mod changes and roll them back if they are undesired. The go.mod file might not be under my control. If I want to list modules I will have to revert changes in go.mod again and again. I understand the intention of this behavior: to keep go.mod in a good shape and to add mandatory entries there, it is totally reasonable to have this behavior by default, but it would be great to have a mode with this logic disabled.

[tv42]

but it would be great to have a mode with this logic disabled.

That'd be -mod=readonly, I believe.

[gopherbot]

Change https://golang.org/cl/204521 mentions this issue: cmd/go: default to mod=readonly when the go.mod file is read-only

[gopherbot]

Change https://golang.org/cl/204821 mentions this issue: modfile: ensure that Cleanup removes extraneous entries after SetRequire

[gopherbot]

Change https://golang.org/cl/204877 mentions this issue: cmd/go.mod: upgrade x/mod to pull in CL 204821

[gopherbot]

Change https://golang.org/cl/204878 mentions this issue: cmd/go: make commands other than 'tidy' prune go.mod less agressively

[gopherbot]

Change https://golang.org/cl/205497 mentions this issue: modfile: prefer to add a new 'go' directive after the 'module' directive

[gopherbot]

Change https://golang.org/cl/205539 mentions this issue: cmd: update x/mod to CL 205497

[gopherbot]

Change https://golang.org/cl/219237 mentions this issue: cmd/go: eliminate empty '()' when passing -mod=readonly explicitly to 'go list'