Skip to content

cmd/go/internal/modget: avoid queries for workspace modules and verify module using workspace graph #73654

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

Open
matloob opened this issue May 10, 2025 · 1 comment
Assignees
Labels
ToolProposal Issues describing a requested change to a Go tool or command-line program.

Comments

@matloob
Copy link
Contributor

matloob commented May 10, 2025

go get doesn't work well when run from modules in workspace containing unreleased modules.

go get expects to be able to find modules to require to satisfy all imports and also checks that the module can be loaded properly. So when one of the workspace modules is not released, any queries to find imports of packages in that module will fail, and go get will not be able to get to finding modules to satisfy imports that are in released modules. Even if we could avoid that, there would be another problem: the final load of the module will not succeed in module mode because the module is missing requirements to satisfy the imports in the unreleased imports.

We plan to address the first problem by having go get avoid queries to try to satisfy imports from in the work module of packages that exist in the modules used in the go.work that would be used in workspace mode. This is a little ugly because it does affect the behavior of go get, but it's a minimal change, and results in go get only loading the single module's build graph to determine the changes go.mod. We will not avoid queries of a package in one of the workspace modules if they are explicitly specified on the command line.

We will address the second issue by having go get do the final load in workspace mode. Any major issues and missing requirements of packages outside the workspace will still be detected.

One case this does not solve, that we may need to keep an eye on, is when multiple workspace modules have missing requirements from different modules outside the workspace. A go get in any of those modules will fail.

@matloob matloob self-assigned this May 10, 2025
@gabyhelp gabyhelp added the ToolProposal Issues describing a requested change to a Go tool or command-line program. label May 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ToolProposal Issues describing a requested change to a Go tool or command-line program.
Projects
None yet
Development

No branches or pull requests

2 participants