more plugin compatibility helps with shared plugins and a plugin marketplace
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…
register converters, which handle the type translation.
register a converter
register 2 incompatible plugins.
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
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)
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
support events / callbacks before a plugin/action is about to process on an instance.
then we can subscribe to this, and somehow capture the instance and convert it.
something similar to the filter-plugins setup
a decorator around the process function allows you to do whatever
convert the instance to your fav type
but how do you manage each individual plugins convertors
after you ran your collectors, run a convertor plugin that collects the instance as a new instance
creates a lot of instances and results in a messy workflow
doesn’t support collecting instances afterwards, relies too much on order
every plugin has a input-type, and output-type if it creates instances.
pyblish-base lets you register convertors, just like plugins, hosts, gui
if a plugin runs, it gets the instance, then before it runs, it asks for the type of the isntance.
if this does not match the input type, we check our registered convertors.
if there is a matching one, it can be converted, else error like usual.
needs extra functionality added to pyblish-base
seems like the most work, but can’t see why this wouldn’t work
found a solution that works as a collector / plugin based approach.
it creates a single instance instead of 1 instance for each instance of another type
then that instance collects all other instances when it’s iter function is accessed.
it seems to work fine
test code registering a collector and validator with 2 different families.
def __init__(self, converter_function, input_families, *args, **kwargs):
input_families: the family to find instances that need converting
family/families: the family used by validators to find the converted instances
:param converter_function: function to convert the instance, can be a generator or anything iterable.
self.converter_function = converter_function
self.input_families = input_families
super(ConvertorInstance, self).__init__(*args, **kwargs)
context = self._parent # does not yet support instances parented to other instances, only parented to context
mock_plugin = pyblish.api.Plugin
mock_plugin.families = self.input_families
original_instances = pyblish.logic.instances_by_plugin(context, mock_plugin)
self.converted_instances = self.converter_function(original_instances)
for instance in self.converted_instances:
when testing with the GUI it is unclear which instance failed the validation for now
same with clarity on which instance was successfull.
i think we can get around this if we register convertors in pyblish, just like how we register paths, plugins etc.
and dont treat convertors as standard plugins.