proposal: cmd/go: make go get leave go.sum in a tidy state

[andig]

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

$ go version
go version go1.17.2 darwin/arm64

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
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/andig/Library/Caches/go-build"
GOENV="/Users/andig/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/andig/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/andig/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/homebrew/Cellar/go/1.17.2/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/homebrew/Cellar/go/1.17.2/libexec/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.17.2"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/andig/htdocs/evcc/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 -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/sv/rs_453y57xj86xsbz3kw1mbc0000gn/T/go-build1792195164=/tmp/go-build -gno-record-gcc-switches -fno-common"
GOROOT/bin/go version: go version go1.17.2 darwin/arm64
GOROOT/bin/go tool compile -V: compile version go1.17.2
uname -v: Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:24 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T8101
ProductName:	macOS
ProductVersion:	12.0.1
BuildVersion:	21A559
lldb --version: lldb-1300.0.32.4
Swift version 5.5.1-dev

What did you do?

go get github.com/philippseith/signalr@master

What did you expect to see?

A go.sum that will not change when go mod tidy is run.

What did you see instead?

go.sum containing both old and new commit of downloaded module.

My projects use git porcelain to check everything is up-to-date and tidy, including running go mod tidy before. To achieve that state, a go get almost always need be followed by go mod tidy. It would be nice if that was the default or optional behaviour of go get.

[thanm]

@bcmills @matloob

[rsc]

go get does a lot less work and loads many fewer packages than go mod tidy does.
Making go get tidy go.sum (and go.mod) would make it more expensive.
It's unclear that's worthwhile. If you need go mod tidy, it's easy to run.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[andig]

go get does a lot less work and loads many fewer packages than go mod tidy does.
Making go get tidy go.sum (and go.mod) would make it more expensive.
It's unclear that's worthwhile. If you need go mod tidy, it's easy to run.

go get does a lot of work when fetching resources from the network and is often quite slow for me. I would expect go mod tidy to be much quicker when the entire structure already exists locally.
I'm wondering if there's perhaps a subset of go get operations (like for simple updates as described above where a single main dependency is upgraded without side effects) that could be included?

Happy to have this closed if not feasible, thank you.

[bcmills]

I think there are some cases where go get could maintain more cleanliness than it does today, although I agree that it isn't feasible to make it as precise as go mod tidy.

The cases where it would be straightforward to add precision are:

1. If some version of a module was present in the module graph at the start of go get, and that version is no longer present in the module graph after go get, then we could reasonably discard the go.mod checksum for that version. (We know that it used to be needed to compute the module graph and no longer is.)
2. If some version of a module was selected in the module graph at the start of go get, and that version is no longer selected after go get, then we could discard the zipfile checksum for that version (and perhaps download the newly-selected version and add its checksum).

That said, those increases in precision still wouldn't guarantee that go get preserves tidiness every time. (For example, the import graph can change arbitrarily in packages that are not relevant to the specific package requested on the command line, which can cause previously-irrelevant checksums to become relevant or vice-versa.)

[rsc]

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

[andig]

I‘m a bit confused with the summary. In terms of „always“ tidy it seems that it‘s a decline. In terms of „more often tidy than today“ it seems to be „accept“. Just to clarify- the latter would imho be better than nothing. If not worth complexity vs benefit a brief comment would be appreciated.

[rsc]

No change in consensus, so declined.
— rsc for the proposal review group