Pyblish_qml and pyblish_lite deviations

Hi,

I wrote a simple series of pyblish plugins for testing purposes and I realized that some of the code runs differently under pyblish_lite that it would under pyblish_qml.

1.) Is it not true that lite vs qml are sole front end of the pyblish and every plugin in theory should behave the same ?

code:

class DebugFixAction(pyblish.api.Action):
    '''run a plugin's debugfix on every failed instance'''
    label = "Debug-fix"
    def process(self, context, plugin):
        self.log.info("Running {} auto-fix".format(plugin))
        from pprint import pprint
        for inst in context:
            pprint(inst.data())

pyblish_lite output:

>>>
{u'__families__': ['placeholder'],
 u'_has_failed': True,
 u'_has_processed': True,
 u'_has_succeeded': False,
 u'_is_idle': False,
 u'_is_processing': False,
 u'_type': u'instance',
 'family': 'placeholder',
 u'label': u'def_placeholder_grp',
 'name': u'def_placeholder_grp',
 u'optional': True,
 u'publish': True}

stacktrace:
#   File "/mnt/ps-storage01/appdepot/dev_packages/<user>/python_extras/0.9.1/python-2.7.17/site-packages/pyblish_lite/control.py", line 100, in on_next
#     result = pyblish.plugin.process(plugin, context, None, action.id)
#   File "/mnt/ps-storage01/appdepot/dev_packages/<user>/python_extras/0.9.1/python-2.7.17/site-packages/pyblish/plugin.py", line 466, in process
#     result = __explicit_process(plugin, context, instance, action)
#   File "/mnt/ps-storage01/appdepot/dev_packages/<user>/python_extras/0.9.1/python-2.7.17/site-packages/pyblish/plugin.py", line 517, in __explicit_process
#     runner(*args)
#   File "/mnt/ps-storage01/appdepot/dev_packages/<user>/assettools/0.4.0/python/studio/pyblish/pyblish_checks/placeholder_check.py", line 48, in process
#     import pdb; pdb.set_trace()

pyblish_qml output:

>>> {'family': 'placeholder', 'name': u'def_placeholder_grp'}

stacktrace:
#   File "/mnt/ps-storage01/appdepot/dev_packages/<user>/python_extras/0.9.1/python-2.7.17/site-packages/pyblish_qml/ipc/service.py", line 97, in process
#     action=action)
#   File "/mnt/ps-storage01/appdepot/dev_packages/<user>/python_extras/0.9.1/python-2.7.17/site-packages/pyblish/plugin.py", line 466, in process
#     result = __explicit_process(plugin, context, instance, action)
#   File "/mnt/ps-storage01/appdepot/dev_packages/<user>/python_extras/0.9.1/python-2.7.17/site-packages/pyblish/plugin.py", line 517, in __explicit_process
#     runner(*args)
#   File "/mnt/ps-storage01/appdepot/dev_packages/<user>/assettools/0.4.0/python/studio/pyblish/pyblish_checks/placeholder_check.py", line 48, in process
#     import pdb; pdb.set_trace()

Question:
1.) Is it not true that lite vs qml are sole front end of the pyblish and every plugin in theory should behave the same ?
2.) Why do pyblish_qml/ipc/service.py and pyblish_lite/control.py fill context data differently ? Is there a reason for that ?
3.) I am after the instance.data '_has_failed': True flag to run automated fixes on failed instances. Do failed instances have to be queried differntly using pyblish_qml ? What’s could be a good temporary solution here ?
pyblish_lite

class DebugFixAction(pyblish.api.Action):
    '''run a plugin's debugfix on every failed instance'''
    label = "Debug-fix"
    def process(self, context, plugin):
        self.log.info("Running {} auto-fix".format(plugin))
        # from pprint import pprint
        # for inst in context:
        #     pprint(inst.data())

Hi @enno.s,

You’re right that they should behave the same, anything else is a bug that it would be great if you could file.

They are however two different UIs that implement handling of Pyblish differently, mostly because of how Lite runs in your host like Maya and how QML runs as a separate process with a somewhat more complex communication route.

That said, both Lite and QML embed their own bespoke information into the data dictionary, for internal use. Generally, if it isn’t documented it isn’t meant for public consumption and _has_failed appears to be such a variable.

There’s something better than a temporary solution I think, see context.data["results"] for a wealth of information regarding plug-ins that has run. Each time a plug-in is run, all of the intermediate information - such as failure state - is embedded into a “result” each.

See the Report section in the Pyblish by Example series. And here for a full definition.

1 Like

Thank you very much,
That is working for me so far.

1 Like