Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: module dependencies added from different go.mod files of single module at different versions #35884
What version of Go are you using (
Although the sample reproduction is contrived, I ran into this issue in a real scenario when converting repositories with a circular dependency to modules (where both repos also pointed to a common repository where a submodule was later created).
Because minor versions aren't collapsed, the circular import made it such that the module was considering both its current dependencies and the dependencies of its previous version, which was very confusing to reason about.
If the underlying issue itself won't be fixed, it would be helpful to have documentation somewhere that notes that the module dependency graph will consider dependencies of all versions of dependent modules, including all different minor/patch versions of the same module.
I think the issue here is that both modules
The requirement on
There are a couple ways to resolve this.
You could try eliminating the requirement on
You could tag a new version of
Hope this helps. Closing since this is working as intended, but I'm happy to answer questions.
@jayconrod thanks for chiming in -- adding
It would be helpful for me to clear up this conceptual question, though:
If that's just the way things are then that's that, but this is the portion that I would specifically like to understand. That's the part that felt like a bug/incorrect behavior on my end without further knowledge -- since my understanding was that only one major version of a module was used per build, the fact that the dependencies of multiple different versions of the same module were being used in analysis seemed strange to me and was unexpected.
The requirement on a newer version of
This comes up mostly when a single large module is split into submodules. For example, take a look at the
That's true when it comes to loading and building packages, but not for reading
To summarize though, think of each version of each module in a directed graph. Requirements in
(Sorry this isn't documented somewhere more obvious by the way. I'm working on improving the documentation for 1.14 (#33637)).
Thanks! Yes, I think the main source of confusion for me was that import path conflicts could happen based on dependencies introduced by different versions of the same module -- I thought that these conflicts would only matter if they existed at the build list level, but it makes sense that this would be an error even at the module dependency construction level (and thus consolidating module versions to a single one at that point doesn't prevent the error).
I believe I fully understand the contracts now, and appreciate the tip for adding the requirement to the submodules to help prevent issues for other consumers. Thanks!