Dependencies between Plug-Ins

Hey!

We’re currently facing a small issue with dependencies between the Plugins that we are writing (an Integrator relying on context.data["currentFile"], as a simple example). As a short precursor: We’re testing every Plugin by registering it alongside the other Plugins it requires, running the Publishing process in a pre-created scene, and asserting that the results match what we want to see. So if any Code changes would break anything, our tests can catch it before we deploy it. So at the moment, we’re just manually registering all the Plug-In dependencies in the test.

We also have a system for toggling specific Plug-Ins for specific contexts (project, asset category, sequence, shot, …), but we’re afraid that this flexibility could lead to someone accidentally disabling a Plug-In that is necessary for another Plug-In to work.

With more and more dependencies between Collectors, Extractors, and Integrators popping up, we wanted to look into a way of either:

  • Generating a graph that displays all dependencies by manually supplying what data this Plug-In uses and the data it sets. This would at least allow us to have a nice overview whenever we need it (for the docs, as an example).
  • Creating our own function for registering a Plug-In with its dependencies (probably gathered by a cached result of the graph from the last point)

I saw that the Plugin Classes have a requires attribute, but that seems to only support checking the Version of pyblish itself. Is some mechanism like that already present in Pyblish or do we need to come up with our own solution? How would you guys go about this problem / What do you think of my proposed solution?

Thanks in advance for any help / feedback on this topic!
Cheers,
~ Matthias

Hi @Etherkirby,

I like your idea, and have explored similar things for Pyblish in the past, a few that comes to mind (seach for “graph” or “node” amonst issues)

As for generating a graph, what would your additional dependency metadata add that isn’t already provided by the families attribute? That is how plug-ins and instances currently advertise their compatibility and has so far been able to account for just about any dependency I’ve come across.