Although I’m the biggest fan of repairs, I am seeing more and more why the current repairing system isn’t working when having them in production.
This may be my fault, but I’m finding that I need an order of repairing instances. Currently if you instruct artists to hit “Repair” when they find them, they will do so in the order they see them in the UI.
The problem with this is that if you have two validators working on top of each other. Case study is these two validators;
ValidatePathExistence: This plugin validate whether the directory of the instance output exists.
ValidatePathLocation: This plugin validate whether the directory of the instance output is correct.
When the artist sees this in the list, they might create unnessecary directories when the path location is uncorrect to begin with but artist sees the repair button for the path existence first.
This is a simple example to get the idea across, but its a growing problem with increasing amounts of repair methods on instances.
I’m an advocate of getting a system in place for repairing, as it will speed up production but maybe I should wait for the “Event Driven Processing” feature; https://github.com/pyblish/pyblish/issues/143
It’s a clash in responsibilities. Pyblish should never have offered to repair anything in the first place, and as much as I’d love to deprecate it, there is definitely something to the fact that coupling validations with solutions is incredibly intuitive. We’re just not using it right.
If we were to think outside the box for a moment, how else could we offer users the ability to solve failed validations, keeping solutions coupled to validations like we are currently via repair_instance within the same plug-in, but with less ambiguity and more room to grow?
The traditional method is to just offer menus, shelves or an additional GUI. This way, each solution have full control over how repairing is managed and could even come with its own GUI, and merges with surrounding utilities offered to artists that doesn’t necessarily involve repairing.
At the moment, the one benefit of doing this via Pyblish is that it is sensitive to what has failed. We’ll need to find something that retains this benefit, but still gives an advantage to just providing users with a menu item.
I think what I’m flagging here is actually to do with the processing structure. Even if there wasn’t any repair methods on the validators, the artist could still be doing the wrong thing if they fix one validator at a time.
I know this is a simple example and any artist would probably be able to know that they need to get the path correct first before creating folders, but if there are lots of validators this can become a daunting task to figure out.
That why I was pointing to the chaining of plugins, so artists can fix things in the right order.
I wouldn’t say it’s the solution, no. It might help you solve this immediate problem (because it adds more possibility overall), sure, but I don’t think it would be long till you find another roadblock.
From my perspective, repairing is just a subset of scene manipulation. It’s currently the only part where Pyblish interacts with your work and it’s a completely different mechanism and implementation from publishing with a completely different mindset and requirements
I think Actions is a good way forwards; primarily because it clearly decouples processing from interaction and doesn’t lure developers into thinking further about ordering or additional visualisation and inspection of results and any other complex requirement that may appear. It’s just an action, a singular atomic operation. Which is more or less what repair is today, except that it’s not as obvious because it looks like it’s the same mechanism as process_instance et. al.
With Actions, I think it might have become more obvious to you when thinking about providing a complex repair that it wasn’t suited for the level of complexity you need. And if you should still decide to go for it, then it would become clear that you would need to build a surrounding system to handle it properly, as opposed of relying on Pyblish too much.
I think what I’m trying to say is, think of repair today as Actions in the future. Keep it simple, and if you ever need more, take it outside. There’s definitely room for a feature rich software when it comes to repairing and I don’t see a reason why we shouldn’t develop it. It could build on the same methodology as Pyblish, even use the same physical plug-ins (e.g. using repair instead of process) but operate inwards, doing scene manipulation, as opposed to outwards, validating and serialising, which is what process does today.
Just wanted to say that I really like how you’ve kept your mindset (on having Pyblish not perform current scene manipulation) and that this puzzle piece fits neatly into that. Keeping Pyblish focused and still allowing expansion by other devs, it’s a sweet spot.
I’m totally with you guys that repair fills an important gap and I don’t doubt we’ll find a perfect spot for it eventually, we’ll just need to keep spawning ideas.
So do take a moment and consider how else it could work, the sooner we fill it the better.
I do agree that keeping the separation clear is important, but as you say the data you get from pyblish is very convenient for doing repairs as well.
I’ll have a think about what to do about repairing and scene interaction, but still think Event Driven Processing would be important as well for Pyblish.
Take the ftrack extension as an example. There is a hierarchy of objects in ftrack; Asset>AssetVersion>Component. When publishing we need to validate all the way down to the component, but we can’t do that before the asset and assetversion has been validated. This is currently done with the “order” attribute, but to the artist its just three separate validations.
Oh, yes don’t get me wrong, Event Driven Processing is the way of the future. It will give way for the graphical representation of plug-ins as nodes on a canvas and arbitrarily plugging them into each other, encapsulating them into aggregate graphs and will enable sharing and composition on a whole new level.
I just don’t think it’s a solution to scene manipulation from within Pyblish being a bit awkward at the moment.
I’m kind one foot in either camp. On one side I know for a fact, that repairs in validators are very much enjoyed by our artists. It help them get a few technical things of their mind which is exactly why we’re doing this whole publishing business. To get people to spend more time creating and less time worrying about technicalities.
However I’m not a big fan of the fact, that using repair workflow, feels like it’s a part of publishing process. The ideal solution conceptually for me would be 2 tools working on the same principle, same UI style so it’s familiar to people, But one is for ‘Sanitizing’ and one for ‘Publishing’. Artist should know that if his scene is not up to scratch, he won’t be able to publish, so he has the option so sanitize the scene before even attempting to publish.
So how about looking at it this way. Picture 2 semi-separate apps. 1 - Pyblish as it is now and 2. - P-repair (name purely for demonstration purposes )
Both working on the same architecture, sharing most of the code with one big difference.
Pyblish runs all your selectors, validators and stops upon failed validation without giving you option to alter the scene in any way (apart from maybe tiny fixes, like scene not saved),
P-repair runs the same identical selectors and validators so you know you’re gonna be repairing what matters for publishing, but doesn’t have extractors and conformers. Instead if you pass all tests, you get a nice big green tick and pat on the back and if any validators fail, it shows a bunch of ‘repair’ options and stays in a ‘paused’ state, where you can choose which repair to run and when you’re ready, press play again and the process finishes on the failed validators. These repairs could be another class of plugins, actions or whatever implementation.
The point is that artist would run P-repair whenever they want to do a check on the scene. Even while working on a scene to prevent too many mistakes from piling up over time. I image p-repair would load all publishing validators by default, but you could add extra validator that would only appear here, but not during publishing.
This could give a clear distinction to artists where the line is between repairing problems and publishing a clean scene, while also keeping the benefits of existing SVEC workflow. If it was built on the same base as pyblish (I really thing they’re almost identical in this example) we could avoid and double code for the users as they could simply load the same selectors that will eventually be ran for publishing of the same scene.
)