Thanks for the input guys, really good questions raised here!
They'll run like any other plug-in. The difference here, both technically and practically, is that there order is altered to a range outside of the current SVEC plug-ins, such as
1000. At this order, they could still appear in the GUI, remain optional and have their own order - for example, create four logical groups of orders such as
1003 and you'll have your very own SVEC-stack.
The lack of a family means they can't operate on
Instance's, so the only thing they have to grab onto is the
Context. We haven't yet put the
Context in the GUI, but once it's there, this would become the only publishable element in a scene and the one every
SimplePlugin would operate on.
It's a good question, and it's possible they can/should. As they would remain identical to other plug-ins, there's nothing stopping you from creating a stack similar to this.
order = 1000
def process_context(self, context):
instance = context.create_instance(name="MyInstance")
order = 1001
families = ["myFamily"]
def process_instance(self, instance):
# process MyInstance here
The difference here is that the step would be come optional.
Remember the primary goal of this proposal is to reduce the learning curve for beginners. The primary question then is whether it would lengthen the learning curve for doing anything advanced with it.
If it turns out that it also opens up new doors, then that's great I think!
But, as currently described, it being of no particular use
No no, you misunderstand. They are of no particular purpose. As opposed to SVEC which all have a particular purpose or "destiny"; e.g.
Validator's are meant for validation whereas
Extractor's are meant for serialisation.
SimplePlugin on the other hand can do this too, but its purpose would be delegated from the framework to the developer. It is up to you to define their purpose.
Does that make more sense?
Yes, it might.
I think the main goal of doing this would not be to remove the SVEC-stack, but to delay it until after a developer has had experience with implementing the first set of plug-ins in his pipeline. Maybe an illustration is in order.
This is now. When learning Pyblish, one first has to learn about the API, obviously, but they also must understand SVEC. Before they can understand SVEC however, they need a rationale, a reason for why SVEC has been designed as it has, why selection must come before validation.
Once they've passed this bar, they can start implementing their first plug-in and spend the rest of their days learning about the proper use of SVEC.
This on the other hand is how I'd like it to be.
The user learns about the API, which essentially becomes
process_context and the fact that it runs when you publish, followed by writing their first plug-in.
From there, it is up to them whether they want to pursue an established standard such as SVEC or whether they want to roll their own.
Beyond Initial Intentions
It's true that given this power users are able to do anything. Even import things into their scene or use Pyblish as a collection of arbitrary tools unrelated to publishing.
But let's look at an example beyond Pyblish.
Qt is a framework and it has certain best-practices. I'm still learning about them after all these years and I doubt I'll be able to grasp them all, not to mention have use for them all. But if using Qt meant that you first had to learn about it's best practices, I would still not be using it to this day.
So the question is, would I even have gotten past the learning phase?
Odds are I would have glanced at the up-front cost of using it, and headed elsewhere. Something that could instead get me up and running more quickly and learn at my own pace.
Even though Pyblish is no where near the complexity of Qt, we're doing exactly this on a smaller scale. A new user is unable to start learning on his own, but is instead force-fed our vision of publishing and the SVEC stack. What I'm looking for is a shorter path from learning to using.
And again looking at Qt, because it makes such few assumptions, everyone uses it in their own way, but they as a company, and a majority of their advanced users still make good use of their proposed workflows and convenient functionality, such as MVC and QAbstractItemModel, even though no one is forced to use it.
Some more example, Python does everything, but has it's "Zen of Python". Often when asking questions about how to do something with Python you get as answer "This is the Python-way of doing it". SVEC could be the "Zen of Pyblish" in this respect.
Docker is another example; it's a general purpose method of encapsulating multiple processes into one process, but has guidelines about how to do it for the greatest amount of flexibility. When everyone follows the guidelines, everyone works together towards a common goal. But you don't have to if you don't want.
Anyway, this I think summarises my motivation. Maybe
SimplePlugin isn't a way to get there, but I think it's good that we're having the conversation.