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
x/vgo: list -m includes spurious dependencies #24150
What did you do?
This module list includes quite a few dependencies that are not actually dependencies of the chosen
The reason appears to be that dependencies are included if they're in the dependency list as it's first calculated.
That commit of the
and that particular commit of the
However when all the dependencies are finally resolved, we end up using v0.0.0-20170608054451-2fe0e88cf232 of
I would suggest that the modules listed by
Also reported in the comments to Russ's Minimal Version Selection article, where ezyang points out that the algorithm as described doesn't seem to prune unused dependencies.
The hard thing about unused dependencies is they are build tag dependant. While there is a maximum dependency graph for all tags, it is reasonably common to not care about a subset of them.
In other words, there are three definitions of unused:
It would be nice if go list could take a tag Boolean expression and report the use status of the module. We could then use that primative to compute and of the thee views above. Then to prune something like:
Re @magical's comment, this is working as designed & intended. Including D 1 in the build list is part of making sure there is a single, minimal, unique answer. Consider:
A -> X
Even though A->X, A->Y, X->B 1.1, Y->B 1.2 implies that we're going to use B 1.2, it's still important to chase down what B 1.1 wants and incorporate that information, because that's what X wants too. X is being built against D 1.2. If we didn't follow into B 1.1, we might build X with too old a D and not be able to build at all.
In the case where B 1.2 does not depend on D at all, then there's an argument for dropping D from the go list -m output, but we still have to look and see what D 1.2 in turn requires and apply any of its constraints to move any versions forward.
@rsc With respect, I see this as a different issue, although they are related.
Issue #24101 is about pruning dependencies that are explicitly listed in a
This issue is concerned with the fact that
Yes, I think it's important to drop D from the
I won't reopen the issue, because my reasoning may well be wrong here, but ISTM that it might be worth tracking this issue separately from #24101.
† One thing that I think I'll miss is that with all dependencies explicitly listed (using dependencies.tsv in our case), it was very obvious at code review time when a new major version (often a potential bug, not uncommonly introduced when using goimports) was introduced. I wonder what a good approach to dealing with that in the vgo world might be.