You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But what if example.com/q itself has edges to new, not-previously-imported dependencies?
example.com/q v1.1.0 -> example.com/r v1.0.0
With current workspace pruning semantics, that edge will be pruned out: it is pruned out of a's dependency graph (because it is not relevant to any package imported by a), and it is not present in b's dependency graph (because b requires a different version of q entirely).
The result is that a by itself may be tidy, and p by itself may be tidy, but loading the dependencies of p from the combined module graph is missing a dependency.
The text was updated successfully, but these errors were encountered:
However, that loop has a pretty unfortunate running time: any time a dependency is upgraded it reloads the full graph to recompute MVS results, and upgrades can potentially form long spirals. In a single-module setting, that's not terrible because we can record the result in the go.mod file for next time, but in workspace mode we don't have any obvious place to record it.
Another possible fix is to change the workspace pruning mode to do the expansion itself: after each round of loading from the roots, re-enqueue the selected version of each root if that version's dependencies have not yet been loaded.
(That would take the form of an extra condition and perhaps another layer of looping in modload.readModGraph.)
If we end up encountering a spiral of upgrades, that doesn't allow us to prune out as many intermediate versions, but it does allow us to avoid reloading the graph multiple times — and upgrade spirals seem like they will be fairly short in practice and are relatively easy for the user to cut off by running go work sync.