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.
Comment From: gabyhelp
Related Issues
- cmd/go: workspace detected outside of workspace #51604 (closed)
- cmd/go: fix go get with ... fails in module mode #29606 (closed)
- cmd/go: fix go get with ... fails in module mode #29604 (closed)
- cmd/go: Proposal: Modules without releases have the newest code fetched when go get -u is ran. #33722 (closed)
Related Code Changes
- cmd/go: report a helpful error when there are no modules in workspace
- cmd/go: forbid resolving import to modules when outside of a module
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
Comment From: gopherbot
Change https://go.dev/cl/669635 mentions this issue: cmd/go/internal/modget: check in workspace mode if go.work present
Comment From: neclepsio
I this in 1.25rc1? If yes, it does not work for me.
If I run go get -u ./... in a module containing a requirement that go.work replaces (and has no DNS entry), I get unrecognized import path [...]: https fetch: Get [...]: 56;.
Comment From: matloob
@neclepsio Yes the change we made was in RC1. Would you be able to provide steps to reproduce the failure? Does go get work fail with the same error?