Skip to content

cmd/go: should 'go get -m -u' only consider dependencies of the main module? #32038

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.

Sign up for GitHub

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

Jump to bottom
Closed
jayconrod opened this issue May 14, 2019 · 6 comments
Closed

cmd/go: should 'go get -m -u' only consider dependencies of the main module? #32038

jayconrod opened this issue May 14, 2019 · 6 comments
Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone
Go1.13

Comments

@jayconrod
Copy link
Contributor

Since CL 174099, go get -m -u A upgrades module A to the latest version, as well as modules providing packages transitively imported by packages in A. This may introduce requirements on modules not needed to build packages in the main module, i.e., requirements that would be removed by go mod tidy.

For example, suppose that:

  • Module A has packages A/x and A/y.
  • A/y imports B/z in module B.
  • Packages in the main module import A/x, but not A/y or anything else that transitively imports B.

go get -m -u A will upgrade both A and B to the latest version, probably introducing a requirement on B in go.mod.

@bcmills suggested that we tweak the meaning of go get -m -u A a little bit. The -m flag causes us to expand A to the set of packages provided by module A. For the purpose of -u, we could intersect that set with all, giving us the set of packages provided by module A needed to build packages in the main module.

With this change, go get -m -u A in the example above would update A but not B, since the argument A would expand to the package A/x but not A/y.

@rsc Any thoughts? @bcmills and I discussed this for a while this morning, but we didn't reach a conclusion. It seems like a useful change, but it adds some complexity.
@jayconrod jayconrod added NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. modules labels May 14, 2019
@jayconrod jayconrod added this to the Go1.14 milestone May 14, 2019
@thepudds thepudds mentioned this issue May 14, 2019
Closed
@bcmills
Copy link
Contributor

bcmills commented May 14, 2019

I discussed this with @rsc earlier today.
To summarize his commentary:

  • In Go 1.12, since module-mode go get didn't consider the package graph at all, -m meant “stop after computing the new module graph, before loading packages” — it didn't actually change the semantics of the earlier steps.
  • Now, without -m, the upgrade phase of go get loads packages before it even computes the module graph, so there is no logical stopping point in between the two.
  • The -d flag did, and still does, mean “stop after downloading source code”.

Since the -m stopping point between computing the graph and loading packages no longer exists, @rsc suggested that we simply remove the -m flag.

@rsc
Copy link
Contributor

rsc commented May 16, 2019

Yes, let's remove -m. Any uses that want to avoid the build should now use -d (like pre-modules).

@bcmills bcmills added NeedsFix The path to resolution is known, but the work has not been done. release-blocker labels May 16, 2019
@gopherbot gopherbot removed the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label May 16, 2019
@jayconrod jayconrod self-assigned this May 16, 2019
@thepudds
Copy link
Contributor

Milestone here was set to 1.14, but then a day or so later release-blocker was added. Just wanted to double-check if 1.14 milestone is still intended here.

@jayconrod jayconrod modified the milestones: Go1.14, Go1.13 May 17, 2019
@jayconrod
Copy link
Contributor Author

@thepudds Good catch. Now planned for 1.13.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/177879 mentions this issue: cmd/go: remove support for the 'go get -m' flag

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/179361 mentions this issue: cmd/go: recommend -d when -m is used

gopherbot pushed a commit that referenced this issue Jun 7, 2019
@mvdan
cmd/go: recommend -d when -m is used
b23ff2c 
In #32038, it was decided to remove get's -m, since one former use case
is removed, and the other can be done via -d, as pointed by Russ.

However, a user getting this short error might not realise that they can
switch to -d to skip building packages. Add a short mention to point
them in the right direction.

It's important to note "packages", because -m was a flag that acted on
modules, while -d acts on packages. Simply replacing -m with -d might
not be enough in some cases because of that distinction.

Change-Id: I0947b25c4223bdad3cd0e535848527da8db8a16d
Reviewed-on: https://go-review.googlesource.com/c/go/+/179361
Reviewed-by: Jay Conrod <[email protected]>
Reviewed-by: Bryan C. Mills <[email protected]>
Run-TryBot: Daniel Martí <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
@golang golang locked and limited conversation to collaborators May 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
None yet
Milestone
Go1.13
Development

No branches or pull requests
5 participants
@rsc @jayconrod @bcmills @gopherbot @thepudds