Description
Description
Originally discussed in #682.
When working with a large fpm project it can be of interest to study the dependency graph at different levels, including
- the package dependency graph, obtained by recursing through the project
dependencies
- the module dependency graph, obtained by recursively scanning the project (and dependency) modules
The package dependency graph may be of interesting for auditing which packages are used, identifying critical packages (e.g. to provide additional support, or to avoid in case of concerns) and other tasks associated with control of the software supply chain.
Possible Solution
I propose adding a new sub-command for graph generation
> fpm graph [...options...] [-o file.dot]
By default fpm graph
will write to standard output in the DOT language. This way the output can be piped directly to the dot
command, e.g.
> fpm graph | dot -Tsvg -o graph.svg
A couple ideas for options what may be worth adding:
--exclude-dependencies <string or regex>
(for hiding large packages)--max-depth N
(to limit the depth; default would be unlimited)- further options controlling
graphviz
attributes; we should have sane defaults so these should be rarely used. the user can always modify the.dot
file if needed
The implementation of this feature uses the information provided in the resolved dependency_tree_t
and generates the DOT output. Here's an example of the result:
Additional Information
A related issue for module dependencies is in #687.
I'm not sure yet if the module dependency graph should be a separate sub-command, a separate tool or just a switch of the build
sub-command. Whereas the package graph only needs to recurse through the manifests, the module dependency graph requires the full model to be built first. Any opinions about this?