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

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

Open
andig opened this issue Nov 2, 2021 · 7 comments
Open

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

andig opened this issue Nov 2, 2021 · 7 comments

Comments

@andig
Copy link
Contributor

@andig andig commented Nov 2, 2021

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

@thanm thanm commented Nov 2, 2021

Loading

@andig andig changed the title cmd/go: proposal to make go get leave go.sum in a tidy state proposal: cmd/go: make go get leave go.sum in a tidy state Nov 2, 2021
@gopherbot gopherbot added this to the Proposal milestone Nov 2, 2021
@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Nov 3, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Nov 3, 2021

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.

Loading

@rsc rsc moved this from Incoming to Active in Proposals Nov 3, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Nov 3, 2021

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

Loading

@andig
Copy link
Contributor Author

@andig andig commented Nov 4, 2021

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.

Loading

@bcmills
Copy link
Member

@bcmills bcmills commented Nov 4, 2021

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

Loading

@rsc
Copy link
Contributor

@rsc rsc commented Nov 10, 2021

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

Loading

@rsc rsc moved this from Active to Likely Decline in Proposals Nov 10, 2021
@andig
Copy link
Contributor Author

@andig andig commented Nov 10, 2021

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.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Likely Decline
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants