Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

a sub-command to output module inter-dependency information #863

Open
jmtd opened this issue Aug 15, 2023 · 1 comment
Open

a sub-command to output module inter-dependency information #863

jmtd opened this issue Aug 15, 2023 · 1 comment
Labels

Comments

@jmtd
Copy link
Collaborator

jmtd commented Aug 15, 2023

Describe the solution you'd like

I'd like a cekit sub-command that output some kind of structured information that described the image descriptor and module inter-dependencies. e.g. (spitballing)

cekit --descriptor image.yaml graphviz --output deps.dot

A suitable format might be Graphviz's dot language, e.g.

digraph {
  "image descriptor" // [ properties ];
  "some module" //  [ properties ];
  "another module" //  [ properties ];

  "image descriptor" -> "some module";
  "some module" -> "another module";
}

resulting in (when procssed by dot):
example

I guess cekit could (optionally) also invoke dot, so something like

cekit --descriptor image.yaml graphviz --output deps.dot --output-png deps.png

perhaps.

Additional context

Cekit's module dependency system is quite sophisticated and there are some subleties that make figuring out precise module dependencies quite tricky:

  • a module may depend upon a module name which is provided by more than one other module
  • sometimes this is resolved by module versions
  • various other corner-cases

As an image maintainer, it's sometimes necessary to map out which images depend on what modules, and what modules depend on others, to understand the impact of proposed changes.

Attempting to resolve this outside of cekit, effectively duplicating cekit's module-dependency logic, runs the risk of missing a subtlety and therefore generating misleading information. Adding a command such as this inside cekit ensures the output will correspond exactly to Cekit's module-dependency-resolution logic, even as it changes over time.

Next steps

I'd be grateful if the first step was a ACK/NACK on the concept, and then we can get into the weeds of implementation design. I'm happy to get involved in implementing this, but it's been some time since I've hacked on Cekit to any significant extent.

@jmtd jmtd added type/enhancement status/review Sheduled for a review labels Aug 15, 2023
@rnc
Copy link
Contributor

rnc commented Aug 15, 2023

I quite like this idea! @goldmann ... your thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants