Plugin data converters

proposal: converters

pros:

  • more plugin compatibility helps with shared plugins and a plugin marketplace

cons:

  • would require adding/changing the pyblish base architecture.
  • unsure if easy from a technical POV
    it seems easy on first sight, but afraid i overlooked something and it would snowball

it’d be easier to only allow plugins of 1 type
but sharing plugins between a cmds and pymel user would be a pain.
though the enduser can always make their own collector plugin that converts the instances…

proposal:

register converters, which handle the type translation.

  1. register a converter
  2. register 2 incompatible plugins.
  3. before a validator plugin runs on an instance colelcted by the first plugin,
  • it checks if it’s compatible.
  • if not, it checks if any suitable converters are registered.
  • if not, it fails

example

a collector collects instances with meshname
a validator requires a pymel mesh, and would error it tries to do instance.verts

before we run def process(self, instance):
pyblish would check for compatibility between plugins.
notice they are not compatible. and see if any suitable converters are registered.

the converter would take all data in the instance, and translate it. (and cache it for future validator plugins)

goal

the goal is to make collectors and validators written in different languages compatible.
pymel, openmaya, cmds cmdx …

converters can be shared on the “marketplace”, just like plugins

taking the advice of our previous discussion: minimise pyblish core code changes.

this can be a custom plugin instead.
ideally pyblish supports dependencies for plugins.

this is low priority for me so will get back to this when the other features are more fleshed out.

From what I gather, this seems like an appropriate solution to this problem.