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

Modify go get -u semantics for modules #28400

Closed
aanthony1243 opened this issue Oct 25, 2018 · 1 comment
Closed

Modify go get -u semantics for modules #28400

aanthony1243 opened this issue Oct 25, 2018 · 1 comment

Comments

@aanthony1243
Copy link

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

1.11

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

darwin/amd64

When running go get -u <module>, it seems that the semantic should be "update this one module". However, as it is currently documented, it will not only update that module, but also fetch the latest updates from all dependent modules.

To update just a single module, I can run go get <module>, but here I believe the intuitive semantic is "go get this module if you don't already have it."

Proposal: add a -R flag to indicate a recursive module update, so that:

  1. go get <module> only downloads the latest module if the module is currently not present.
  2. go get -u <module> will fetch the latest version of the module according to the rules in go.mod
  3. go get -R <module> will fetch the latest version of the module and also fetch the latest dependencies as well.
@bcmills
Copy link
Contributor

bcmills commented Oct 26, 2018

go get -u <pkg> has meant “upgrade <pkg> and its transitive dependencies” since long before modules. We aren't changing that for module mode: the idea is to extend the existing go get commands to work with modules, not to replace them with an entirely different set.

go get <module>@latest already means what you propose for go get -u <module>.
go get -m -u <module> already means what you propose for go get -R <module>.

If you only want to get a module if no version of it is already active, you can express that intent explicitly: go list -m <module> || go get <module>. (In most cases, though, it's simpler to let go build, go test, or go mod tidy fetch missing module dependencies rather than adding them explicitly yourself.)

At the moment there is a bit of ambiguity as to whether “transitive dependencies” should apply to packages or to modules in the absence of the -m flag (#26902), but in most cases that does not significantly change the outcome.

See also #28156 and #27643.

(CC @rsc)

@bcmills bcmills closed this as completed Oct 26, 2018
@golang golang locked and limited conversation to collaborators Oct 26, 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

3 participants