cmd/go: add mod tidy -diff

[fishy]

Please answer these questions before submitting your issue. Thanks!

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

go version go1.11rc1 darwin/amd64

Does this issue reproduce with the latest release?

N/A

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

GOARCH="amd64"
GOOS="darwin"

What did you do?

• Remove lines from go.mod and go.sum files
• Run go mod tidy to add them back

What did you expect to see?

go mod tidy should return non-zero as it made changes. This way it could be integrated to tools like pre-commit hooks to make sure that we don't commit untidied go.mod and go.sum files into version control

What did you see instead?

go mod tidy returned zero

[mvdan]

Non-zero exit codes are usually for errors, so having it behave like this by default would be counter-intuitive.

Perhaps it could have something similar to gofmt, which has the -l and -d flags to tell if any changes were made.

[swtch1]

If the files are successfully added why wouldn't you want to see a 0 status code? This means that the following script would fail:

#!/usr/bin/env bash
set -e
go mod tidy  # <-- non 0 return code
echo 'we never get here'

[fishy]

That makes sense. How about maybe make it optional? e.g. when it's executed with a flag it should return non-zero when it made any changes.

[thepudds]

@gopherbot, please add label modules

[rsc]

We could think about adding a flag that means "don't do the update, but fail if one is needed".
Not sure exactly what to call it but I put -check in the description. Needs more thought.

[nhooyr]

@rsc regarding your comment in #26850

You could use 'go list all -mod=readonly' to check that at least for the current GOOS/GOARCH no changes are needed.

go list all -mod=readonly causes changes for me to go.sum without erroring.

Is this a bug?

[jayconrod]

When this is implemented, we should run this on the TryBots (#31640).

Ideally go mod tidy -check would not access the network, since it will commonly be run in CI environments where network access is restricted. We might want to do so to provide diagnostics though. GOPROXY=off is still a good signal that we shouldn't access the network.

[nmiyake]

This is a feature that we would like to see for our CI environment as well (we want to verify that go.mod and go.sum are in the proper state for all submissions for all possible build constraints).

I echo the sentiment expressed by @jayconrod that it would be ideal if this check could be performed without network access -- is it feasible for the -check mode to verify only that no change needs to be made without making network queries? My intuition is that the information provided by the source code, go.mod and go.sum should be sufficient to make this determination, but I'm not completely sure about this.

[detailyang]

It's would be useful to reduce git conflict in lint scenario

[mcandre]

Networkless operation is a nice to have. Dry-run flags and intuitive exit codes are perhaps a more immediate concern.

[leighmcculloch]

How about maybe make it optional? e.g. when it's executed with a flag it should return non-zero when it made any changes.

This sounds to me like the solution that is most similar to how other tools solve this problem. golint uses this pattern already, and so do other tools like git diff. I'd prefer this over a -check command that alters the other behaviors of the tool because by altering the behavior of the tool there is more to learn and understand.

It'd be good to surface an exit code mode consistently across all the Go tool commands that we routinely use as checks in CI pipelines.

Today running checks for go mod, go fmt, and golint all use unique and unintuitive patterns:

OUTPUT=$(gofmt -d .)
if [[ $OUTPUT ]]; then
    exit 1
fi
golint -set_exit_status
go mod tidy
git diff --exit-code -- go.mod go.sum

We could reuse the pattern demonstrated by golint:

golint -set_exit_status
go fmt -set_exit_status
go mod tidy -set_exit_status

Or, we could take the opportunity to use a term that is used by other tools, like -exit-code:

golint -exit-code
go fmt -exit-code
go mod tidy -exit-code

[bcmills]

@samthanawalla, this should be a fairly straightforward feature to implement, and would be useful for CI tooling.

(This was in the NeedsDecision state pending a final decision about what the command-line flag should be named; @matloob and @rsc may have some thoughts on that.)

[gopherbot]

Change https://go.dev/cl/579055 mentions this issue: cmd/go: add mod tidy -check

[samthanawalla]

@rsc Should we proceed with -diff or wait for the proposal committee to review?

[rsc]

Given the discussion I think it is fine to proceed with -diff.

[gopherbot]

Change https://go.dev/cl/585401 mentions this issue: cmd/go: add go mod tidy -diff

[gopherbot]

Change https://go.dev/cl/587695 mentions this issue: doc/next: document go mod tidy -diff flag

[gopherbot]

Change https://go.dev/cl/587941 mentions this issue: cmd/go: add compatibility tests for go mod tidy -diff