Skip to content

Package dependency graph #1108

Open
Open
@ivan-pi

Description

@ivan-pi

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

  1. the package dependency graph, obtained by recursing through the project dependencies
  2. 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:

Image

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?

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions