Open howardjohn opened 1 year ago
If there are things that you do not care about, it's possible to use:
goda tree 'reach(./pilot/cmd/pilot-discovery/...:all, k8s.io/api/authorization/v1beta1) - k8s.io/client-go/kubernetes/scheme'
# or
goda tree 'reach(./pilot/cmd/pilot-discovery/...:all, k8s.io/api/authorization/v1beta1) - k8s.io/client-go/kubernetes/scheme/...'
The other thing that can help reduce the graph is:
goda tree 'transitive(reach(./pilot/cmd/pilot-discovery/...:all, k8s.io/api/authorization/v1beta1))'
But it does seem like there could be a way to list out why a dependency is used in less than 800 lines in the command above.
The main issue in your scenario seems to be that the package is used indirectly from so many package, the full info ends up being too much.
Few ideas that do come to mind how the output could be reduced:
Oh, maybe printing things as layers would help?
// Input graph
A -> {B, Z}
B -> C
C -> Z
D -> C
Ranking, would give us something like:
#0: [A]
#1: [B, D]
#2: [C]
#3: [Z]
Which, then could be printed something like:
#0: A -> B #1
-> Z
#1: B -> C #2
D -> C #2
#2: C -> Z
We can ignore printing the last layer, because it doesn't have any outgoing edges. As for the ranking algorithm, there are multiple options; I'm not sure which would be the best.
As for the command name, maybe:
goda topo [expr]
goda tree reach(...)
is super useful for finding why a dependency is imported. However, for commonly used packages it can be a bit unweildy. An example is below:The issue here seems to be that we have a fan-out and fan-in. For example, a bunch of the trees end with
k8s.io/client-go/kubernetes/scheme
. Then we just have one segment thatk8s.io/client-go/kubernetes/scheme
is not a leaf.I think we can prune off these in some manner to reduce the size of the tree in some way.
I am not 100% sure how this would work, though -- since you effectively lose some of the data if we do this. I suppose "tree" is not an effective way to represent what is really a DAG, so maybe that is inherit to the problem. But it does seem like there could be a way to list out why a dependency is used in less than 800 lines in the command above.
I intend to explore what this might look like, but wanted to open an issue in the meantime