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

dfawley opened this issue Aug 29, 2018 · 4 comments


None yet
4 participants
Copy link

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?


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
    Note go.mod will now contain gomock pinned to v1.0.1.
  3. go get

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


This comment has been minimized.

Copy link

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.


This comment has been minimized.

Copy link

commented Aug 30, 2018

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.

@agnivade agnivade closed this Aug 30, 2018


This comment has been minimized.

Copy link

commented Aug 30, 2018

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:

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 downloads and builds the latest version of and its dependencies (for example,

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

If is already in GOPATH but is not, then go get downloads the latest and builds it against the old copy of

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


This comment has been minimized.

Copy link

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.

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