I’ve been developing with pyblish as part of the work @tokejepsen has done here on the Bait pipeline. There are a couple of observations I’ve made so far which I thought I’d bring up.
One which seems confusing to me is the use of “repair” type actions. If something can be repaired, why not repair it during a publish - rather than providing a right-click to ask a user to? This seems to lead to an unnecessary bad user experience. It also seems that repairing leads to a framework which isn’t designed in a TDD manner and perhaps leads to users never correcting their behaviour.
For the crew here, it seems like the default reaction when encountering a failure is to immediately attempt to repair - without going into details of what caused the errors. So, if we’re going to allow a user to short-cut a known failure, we might as well go ahead and repair during validation and only throw errors following it?
A possible alternative could be documenting the known failure within a plugin and providing a guide for a user on how to correct the problem, accessible from pyblish.
In gist, the Docstring of a plug-in is meant as user-facing documentation for what it aims to guard against. Exceptions thrown on failure is a more direct user-facing message, meant to indicate specifically what went wrong, including specific names of objects and possibly what the user could do about it. Log messages are the intermediary, things you could/should throw as many as you think the user could take advantage of.
Personally, I would implement no repair actions but rather point to tools external to Pyblish that enabled the user to work more efficiently and possible automate certain mundane tasks, such as those typically reserved for repair-like Actions.
I think that’s ok. I think the important bit is that no user is afraid of what might happen to their scene should they hit the publish button. At least if it’s an conscious choice, they are taking responsibility for what happens.
Ah, this whole problem seems to be directly related to our use of pyblish-lite/PySide then. I think I’ll have to investigate how much work it would be to use qml in our setup right now, because this seems to provide the level of feedback and context myself and the crew would ordinarily expect.
Sounds like a good idea. Fewer clicks are better
I guess practically you would have to repair the scene first and then validate afterwards, to make sure it’s actually done.
Imagine the terror when having finished your work, ready to publish, only to find it wrecked or worse yet crashed by your friend Mr Publisher. Once it’s done, the scene isn’t what you gave to it but some mutilated version, automatically “fixed” by pipeline TDs. Let’s have it automatically save when finished as well, save the artist some more time. Win!
