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: should 'go get -m -u' only consider dependencies of the main module? #32038

Open
jayconrod opened this issue May 14, 2019 · 5 comments

Comments

Projects
None yet
5 participants
@jayconrod
Copy link
Contributor

commented May 14, 2019

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.

@bcmills

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Contributor

commented May 16, 2019

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

@thepudds

This comment has been minimized.

Copy link

commented May 17, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented May 17, 2019

@thepudds Good catch. Now planned for 1.13.

@gopherbot

This comment has been minimized.

Copy link

commented May 17, 2019

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

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.