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.

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

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

Open
bcmills opened this issue Oct 10, 2019 · 4 comments

Comments

@bcmills
Copy link
Member

commented Oct 10, 2019

#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 #34534).

CC @jayconrod

@dmitshur

This comment has been minimized.

Copy link
Member

commented Oct 11, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Oct 11, 2019

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

@nd

This comment has been minimized.

Copy link
Contributor

commented Oct 12, 2019

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

This comment has been minimized.

Copy link

commented Oct 18, 2019

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.