x/vgo: list -m includes spurious dependencies #24150
Comments
|
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. |
|
Pruning is #24101; closing this one as working. |
|
@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. |
What did you do?
This module list includes quite a few dependencies that are not actually dependencies of the chosen
gopkg.in/macaroon-bakery.v2module. For examplegopkg.in.yaml.v1should not be there.The reason appears to be that dependencies are included if they're in the dependency list as it's first calculated.
For example,
gopkg.in/yaml.v1appears to be present because thedependencies.tsvfile forgopkg.in/macaroon-bakery.v2contains this line:That commit of the
gopkg.in/juju/environschema.v1module has these lines in itsdependencies.tsvfile:and that particular commit of the
github.com/juju/testingmodule usesgopkg.yaml.v1.However when all the dependencies are finally resolved, we end up using v0.0.0-20170608054451-2fe0e88cf232 of
github.com/juju/testingwhich does not depend on yaml.v1 (neither does any other dependency).I would suggest that the modules listed by
vgo list -mshould include only modules that are actual dependencies of the currently calculated versions, not modules that are depended on by versions not in use. It's perhaps telling thatgithub.com/juju/testingis retrieved 6 times. Perhaps the find algorithm needs to be breadth-first, with all immediate dependencies solved before recursing?The text was updated successfully, but these errors were encountered: