I think that yes, it could be nice if there’s a clearer separation of concerns to make sure there’s some expectancy of what should run roughly where.
However, changing the order is honestly cosmetics until we actually hit floating point precision errors for the ordering.
The much bigger issue is the uncertainty on knowing what data you might need is the correct data at a certain moment in time (at a certain order).
What publish plugin at what order generates what data?
A discussion on this came up e.g. here where I’d argue the biggest issue actually is:
- Very hard to visualize currently during a publish what data gets introduced and altered where. So even when developing it’s non-trivial to find out where you can put something to rely on it.
- Since it’s hard to visualize what plug-in touches which data it’s equally hard to really understand what plug-in during the process relied on another plug-in.
For Pyblish I originally wrote this quick prototype debug tool as shown here (bottom of that comment). It shows that it wouldn’t be impossible to have a ‘debug stepper’ UI (if the publisher event callbacks are implemented in e.g. new publisher) to visualize:
- What attributes get created or edited on the instance
- With some clever ‘python logic’ it could also detect which attributes of the instance would get accessed during which plug-in; allowing to visualize what data might be needed by that plug-in. I’m saying might because e.g. debug printing full
instance.datawould of course access all of its data.
With just that data in a debug stepper we could also e.g. list ALL plug-in that touched a particular key/value in instance.data
Having said that, I understand why you might want to nudge some order around. But just reading your post I still don’t understand what would end up where - and thus still doesn’t actually solve the issue of “what/where?”. Which in the end just means, yes - some orders shifted around, but nothing really changes in how easy it is to parse.