cmd/go: no 'go get' command promotes an implicit dependency to an explicit one #43131
Labels
FrozenDueToAge
modules
NeedsDecision
Feedback is required from experts, contributors, and/or the community before a change can be made.
release-blocker
Milestone
While testing some other behaviors for #36460, I noticed a curious interaction between
go get
and-mod=readonly
.If a package or test in the main module directly imports a package found in an implicit (transitive) dependency,
go build
andgo test
invocations for that package with-mod=readonly
will fail withupdates to go.mod needed
, because thego
command has always maintained the invariant that modules directly imported by the main module are explicit requirements.In this situation, the
go
command recommends runninggo mod tidy
, which is usually the first tool users ought to consider for dependency problems. However, a user who does not want to lose other temporary edits to thego.mod
file might prefer to instead usego get
to promote only one specific package instead.Unfortunately, if the module containing the package passed to
go get
is already transitively required at the requested version,go get
does not promote that module from an implicit dependency to an explicit one. (It will under lazy loading, but does not yet.)The user can work around this problem by running
go mod edit -require
to add the requirement explicitly, but we would rather not encourage users to reach forgo mod edit
to make dependency changes, as it does not ensure that the resulting requirements are consistent.Now that
-mod=readonly
is the default (#40728), I think users will be much more likely to encounter this awkward interaction. They may be frustrated by it, and might not consider thego mod edit
workaround.For Go 1.16, perhaps we should make
go get -d
always record explicit dependencies for the requested packages, which can be subsequently cleaned up with an explicitgo mod tidy
.CC @jayconrod @matloob
The text was updated successfully, but these errors were encountered: