After looking over the forums, I have not been able to find this question asked anywhere.
Is there any precedent for running two or more instances of Pyblish-lite in the same session of a DCC?
Context: We are launching pyblish after setting hosts, to control which collectors activate.
register_host(model.save)
model collector collects
deregister_hosts()
register_host(rig.save)
then open the rigging pyblish
The issue of course will be the original model.save pyblish will lose access to its plugins, if refreshed. Or worse, if you do not deregister_hosts() somewhere, when the newer instance pyblish opens, it will have model.save plugins and rig.save plugins.
We are using pyblish.api to power a lot of things for us, and we have come across the issue of having two tools open at once, each with its own list of plugins. But since registering hosts is something accessed by any instance of pyblish, it is messing with the ability to operate independently of each other.
I haven’t come across this usecase before, so it’s a little uncharted territory.
This sounds a little odd; the host should be your DCC, such as Maya. Maybe the targets feature is better suited? Pinging @tokejepsen who has more experience with it, but I think it’d enable one GUI to filter plug-ins differently from another.
Would it be possible to take me through an example of what is being published, how it is validated and potentially extracted/integrated?
I am using hosts so I can control which collectors are being executed at any given time. I did not want to have collectors for modeling, or shaders, present in a situation where I am (or the non technical artist) solely focused on publishing a rig, or xyz.
So I dynamically register the host as needed for the situation I am in. But there is the possibility where someone could have open the Model(pyblish) and then they open the Rig one, and the de/registering of hosts interferes with all instances of pyblish that are open. Or rather, anything that is using the base api.
That is what leads me to inquire about instances of pyblish, or unique tools that use the api, being able to have hosts set in a way that does not interfere with each other.
I know that I am using it way outside of its intended use, its just that plugin system has been very flexible thus far and this has been the only real roadblock so far.
Alternatively, if you have two hosts, modelling and rigging, where modelling have CollectorA and CollectorB, and rigging have CollectorC, could you have validators that apply to both appear for both hosts?
E.g.
class GlobalCollector(...):
hosts = ["modelling", "rigging"]
class ModelingCollector(...):
hosts = ["modelling"]
class RiggingCollector(...):
hosts = ["rigging"]
class ModelingValidator(...):
hosts = ["modelling"]
class RiggingValidator(...):
hosts = ["rigging"]
class GlobalValidator(...):
hosts = ["modelling", "rigging"]
This way, modelers won’t see rigging collectors, but would share some of their validators.
So we preparing for the scenario of sharing plugins and if we plan to have them overlap, its just that we are using the plugin system for so many things at the studio (honestly we could have a call about how we are trying to use it here, like when you showed us some of your cool projects) that being able to control the collectors quickly became needed.
We saw that the only thing they respect is hosts and began to ran with that. Now that the plugin system is creeping into so many tools, we are noticing the registering overlap.
I first came across the idea here,
But eventually went with hosts as a mean to control them.
We want to stay away from modifying pyblish directly, and operating within its own rules. But it looks like we need for a custom tool that is using pyblish.api to have its own hosts(just something collectors respect, like plugins do with families) and coexist with an instance of pyblish(almost stock) doing something else.
Overlap is really common with Pyblish, and the usual way to handle it is to let all collectors run at all times.
What should happen, is that collectors looking for models in a scene with only rigs won’t find any, and thereafter shouldn’t have any effect. Pyblish is built to support an infinite number of collectors, looking for all sorts of things, and only ever find things you have in your scene. This is what’s called “data-driven”, in that the data in your e.g. Maya scene governs what happens.
Those collectors then is responsible for assigning families to the instances it finds, further narrowing down which plug-ins run next. Ultimately, the plug-ins you see in the GUI (and standalone) should only be those relevant to exactly the thing being published; including combination of things, such as when someone tries publishing a rig from a lighting scene.
I think you should give the targets workflow a go. The targets workflow should be able to facilitate your needs. Have a read through these release notes:
