Visualize vendor tree

[F21]

It would be nice if there is a command that can generate a visualized tree of the dependencies in a project.

This would allow us to see what the dependencies of our dependencies (and so on) are.

[sdboyer]

The committee talked about having something like this as part of dep status we certainly see the value in it. PRs welcome to generate graphviz output, that can be piped to e.g. dot and render an SVG :)

[Rhymond]

I'd like to help out with this one. Cloning and checking the code right now.

[mem]

@Rhymond do you have any ideas for an implementation that you might want to share?

[jasonkeene]

I would be nice to see the dependency graph output as text as to not require:

1. dot installed to convert to an image file
2. something to be able to view image files
3. a process such as dep graph | dot -Tsvg > graph.svg && open graph.svg && rm graph.svg

The use case I am thinking of is debugging a build issue in a container in CI where dot wouldn't be installed and getting the generated stuff off of the container onto my box would be needlessly frustrating. Simple things should be simple.

[Rhymond]

hi @mem,

My first and a current idea is to create a string which you can pipe to dot and generate output.
Additional parameters are required by User in process to create output:

• Output directory (Where to store generated image)
• Type [optional] (Output format e.g. png, svg or etc.) (Default: svg)

Now I'm looking how to get dependency tree for project.
Because https://github.com/mem/dep/blob/analyzer_coverage/cmd/dep/status.go#L307 gives only list of dependencies.
In order to get a tree, I suggest to add additional field to BasicStatus struct called parent, to store data from which package that dependency is.

Any advices?

I like @jasonkeene idea to create different output without dot, but for that I think we need to create new issue with new status option.

[sdboyer]

First, a quick clarification - there are two visualizations we might generate: the project dependency graph, and the package/import graph. To this point, I was assuming we were discussing a project dependency graph, but both of these have their uses, so it's worth distinguishing between them.

One reason to draw the line is because they differ in a crucial property: no valid package/import graph can contain cycles, but it's perfectly possible for project-level cycles to occur - see e.g. #171. The possibility of cycles has some implications about what graph visualization techniques are appropriate.

I like @jasonkeene idea to create different output without dot, but for that I think we need to create new issue with new status option.

Agreed, I think this needs to be a different option. It also probably ought to be a tree visualization, rather than making any attempt at drawing a terminal-friendly graph (unless somebody already knows of a magical lib that has already done the work to do that). That's true whether we're talking project or package-level; while I agree with @jasonkeene's sentiment that "Simple things should be simple." graph visualization is not a simple thing.

And, yes, a separate issue, too, please 😄

My first and a current idea is to create a string which you can pipe to dot and generate output.

I think this is the right place to start.

In order to get a tree, I suggest to add additional field to BasicStatus struct called parent, to store data from which package that dependency is.

If we were to add a field, I'd prefer it capture the "child" relationship. All the other declarations a user makes, as well as the raw data (import statements in code, ultimately) we work with is focused on identifying children, not parents.

I can imagine that that might be enough, though - It seems like adding that field should be sufficient to allow people to create scripts that visualize the output as either a tree or a graph. The only disadvantage is that, with the way gps works right now, getting that information right now will make dep status pretty slow.

[jasonkeene]

while I agree with @jasonkeene's sentiment that "Simple things should be simple." graph visualization is not a simple thing.

Agreed. I've looked into git's algorithm for representing the DAG and it is not trivial. I was thinking more from the perspective of the user. The points I outlined above would make for a bad user experience.

[Rhymond]

Hi,

I generated https://github.com/wallix/awless` output.
Does it look correct? Any updates needed?

[sdboyer]

That's generated by an implementation you wrote? Cool! Seems like it's probably pretty good, except that it lacks version numbers.

[Rhymond]

Hi @sdboyer,

Thanks, it was generated by new implementation.
I added version number inside the graph box.

[sdboyer]

this is now merged - woot!

[cjcjameson]

In case folks are looking for instructions on how to use this, here's the place in the docs: https://golang.github.io/dep/docs/daily-dep.html#visualizing-dependencies