Debugging is a key part of our everyday tasks, whether we’re troubleshooting a file in production or ironing out issues with a plugin during development.
1. Publisher’s Details tab
In the publisher UI, we have a Details tab where you can review the logs for each plugin individually. and you can always add as much log statements as you need.
However, You may find log statements quite limited if you’re looking for deeper insights. For example, understanding the changes in context or determining the execution time of the plugin…
The Pyblish Debug Stepper, developed by @BigRoy, serves precisely this purpose!
It provides a Step-by-Step Debugging, enabling you to examine plugins one at a time. At each step, it shows the context and instances along with their data.
Here’s a quick demo
Here are some methods to get pyblish debug stepper.
Note: This tool requires pyblish version >= 1.8.12 ayon-dependencies-tool will get it for you automatically once you run it.
Here’s a snippet from the log
Show the tool window by running inside the script editor.
window = DebugUI()
window.show()
Trigger the validation or publish from the publisher UI or from code.
Finally, check the output step by step.
Method 2: AYON Experimental Tool
You can do that by checking out my branch feature/add_pyblish_debug_stepper_to_exprimental_tools
Within this branch, I’ve included the Pyblish Debug Stepper as an experimental tool that can be accessed from any Host/DCC.
It would be great to update the Pyblish dependency in AYON which would make this feature/tool just that - a tool, instead of requiring the other customizations.
Related question, is there a typical workflow that others use for debugging plugins in their preferred IDE (PyCharm, VSC etc)?
From what I see, the only change needed to get this working (unless I’m mistaken - please point out!) is to compile the py file content prior to six.exec_ in pyblish.plugin.discover.
For example:
with open(abspath, 'rb') as f:
source = f.read()
code = compile(source, abspath, 'exec')
six.exec_(code, module.__dict__)
Apologies if this is a stupid question, or perhaps not the best place.
I believe actually since some code changes in Pyblish and upgrades to Py3 that debuggers should be able to run through Pyblish Plug-ins just fine. It’s been a while ago that I read that somewhere and can’t fidn details about it now.
There was this ancient topic but I definitely do recall running a “remote debug session” with Pycharm and it working fine to set breakpoints inside Pyblish plug-ins. This was maybe a year ago at most.
For the first glance, I didn’t get it but the link that BigRoy’s shared explained it to me furtherly.
Summary, quoted from Marcus.
“You see when plug-ins are discovered on disk, they are loaded as a block of text, rather than imported directly. This is how they are able to reload themselves interactively. It’s possible this throws off any debugger.”
one of the replies suggested replacing the mentioned lines above by the following lines. and the debugger worked with that on their end.
As far as I know, exec is used for executing a dynamically created statement or program. Compile compiles the source into a code which can speed up repeated invocations of the same code with exec or eval.
>>> program = '''
for i in range(3):
print("Python is cool")
'''
>>> exec(program)
>>> exec(compile(program)) # Compile beforehand
Anyways, your code snippet seems to do the same thing as pyblish. loading plugins as a block of text. which we suspect is respnosible for throwing of debuggers.
with open(abspath, 'rb') as f:
source = f.read()
code = compile(source, abspath, 'exec')
six.exec_(code, module.__dict__)
This is likely best asked to Marcus (developer of Pyblish), e.g. on the pyblish forum or pyblish base issues. However, if you do so it might be worth to try and run the debugger again using latest Python. And if it still gives you issues, to then provide the “what you tried” information to pyblish-base issues to raise the questions and the issue you faced.
I recall there having been proposals for changes in the past - and there being accompanying discussions. But for the life of me, I can’t find any now.
Yeah, I think the compile embeds the filepath so it can be used during debugging - the functional difference that seems to make it work (my side) as opposed to current implementation.
