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: module-aware "go get" updates go.mod unexpectedly #27353

Closed
dfawley opened this issue Aug 29, 2018 · 4 comments
Closed

cmd/go: module-aware "go get" updates go.mod unexpectedly #27353

dfawley opened this issue Aug 29, 2018 · 4 comments

Comments

@dfawley
Copy link

dfawley commented Aug 29, 2018

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

go version go1.11 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

not relevant

What did you do?

  1. Create a project with a go.mod.
  2. go get github.com/golang/mock@v1.0.
    Note go.mod will now contain gomock pinned to v1.0.1.
  3. go get github.com/golang/mock

What did you expect to see?

No modifications to go.mod by step 3.

What did you see instead?

go.mod is updated to have github.com/golang/mock pinned to v1.1.1.

go get should not modify a dependency's version in go.mod unless -u is specified.
This is counter-intuitive and behaves differently from the non-module-aware go get, which by default leaves the currently-installed version if one is present, and only updates to the latest version if -u is specified.

@oiooj oiooj added the modules label Aug 30, 2018
@oiooj
Copy link
Member

oiooj commented Aug 30, 2018

From the doc:

For each named package or package pattern, get must decide which version of
the corresponding module to use. By default, get chooses the latest tagged
release version, such as v0.4.5 or v1.2.3.

@agnivade
Copy link
Contributor

Seems like working as intended. You initially have pinned to an earlier version. Now without any @version suffix, it effectively takes the latest tagged version. If you specifically want to pin down to an older version, you would need to use the same tag again.

If you want this behavior to change, I would request you to open a proposal instead, outlining the reasoning behind it and how it will be helpful.

Closing, since this is not a bug.

@thepudds
Copy link
Contributor

Agreed, this is a change in behavior. The rationale behind it is pretty interesting I think. It was described in one of the initial vgo posts:

https://research.swtch.com/vgo-cmd

It’s worth reading that whole post if you are interested, but some related snippets:

the isolation rule:

The result of a build command should depend only on the source files that are its logical inputs, never on hidden state left behind by previous build commands.)

That is, what a command does in isolation—on a clean system loaded with only the relevant input source files—is what it should do all the time, no matter what else has happened on the system recently.

And later:

Plain go get, without -u, violates the command isolation rule and must be fixed. > >

If GOPATH is empty, go get rsc.io/quote downloads and builds the latest version of rsc.io/quote and its dependencies (for example, rsc.io/sampler).

If there is already a rsc.io/quote in GOPATH, from a go get last year, then the new go get builds the old version.

If rsc.io/sampler is already in GOPATH but rsc.io/quote is not, then go get downloads the latest rsc.io/quote and builds it against the old copy of rsc.io/sampler.

Overall, go get depends on the state of GOPATH, which breaks the command isolation rule. We need to fix that.

@dfawley
Copy link
Author

dfawley commented Aug 30, 2018

Regardless of the help text or the reasoning behind the change, this is still a behavior change from how go get worked without modules. This change will confuse users switching to modules, because you are re-using the same get command name and flags that users are already familiar with, but subtly changing what they do.

@golang golang locked and limited conversation to collaborators Aug 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants