cmd/go: 'go mod init' should validate module paths for v2+ dependencies #31549
Labels
GoCommand
cmd/go
modules
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
What version of Go are you using (
go version
)?go 1.12.4
Does this issue reproduce with the latest release?
Yes, including tip.
What did you do?
Observed problems in modules that were ultimately traced back to losing information in the
go mod init
process.What did you expect to see?
go mod init
setting proper module paths for v2+ dependencies when converting from a prior dependency manager.What did you see instead?
go mod init
never seems to set the/vN
as part of the module path for arequire
statementExample from scratch
This can happen in different ways in the wild, but here is an example from scratch.
cda4ac255773
corresponds to the v2.2.0 tag, but therequire
in the createdgo.mod
is missing the required/v2
afterpackr
.In other words,
go mod init
created an incorrect go.mod.Gopkg.lock and Gopkg.toml created by this example
Additional comments
This issue is not about how to resolve this manually, which I know how to do. Rather, it would be better to not to have to resolve manually, but more importantly would better if others did not encounter follow-on issues due to this behavior. Also, in some cases
go mod tidy
or similar can let someone be "lucky" and not notice this, but in some cases the version information converted bygo mod init
is important to avoid follow-on issues.This was a less significant problem early in the history of modules because not many v2+ packages had adopted modules yet.
However, more v2+ dependencies are adopting
go.mod
files themselves as modules move towards being on by default in 1.13.I have seen this behavior be the root cause of hard-to-diagnose problems in the wild, and the rate of those problems likely would increase with more v2+ modules in the ecosystem. (And then later, this problem rate of course would decrease, given it is transitional in nature).
This is related to #30161, but that suggested an alternative solution of dropping the dependency during the conversion process, and that issue was ultimately closed by the reporter after the current behavior was explained and the reporter understood how to manually work around. However, ideally
go mod init
would record the right information here without the need for someone to read documentation or manually work around.The text was updated successfully, but these errors were encountered: