It’s a very important concept, and very relevant. The reason there isn’t any obvious support for this in Pyblish, is because it is expected to be handled via some other mechanism, something out of scope for Pyblish itself, which is related to environment management.
The basic idea is to handle your registrations dynamically.
Right now, you might have exposed a directory for Pyblish to look at by hard-coding it, either when launching the application or by setting it in the local workstation’s physical environment variables for your operating system.
This works, and is great for getting started and getting familiar with Pyblish, but down the line you’ll end up with requirements such as these, and that’s expected. I’d be worried if you didn’t.
So it’s good you bring it up, so we can shine some light on it. Talking about potential solutions certainly isn’t outside the scope of Pyblish.
The quick and dirty
The quickest and most obvious way I would suggest you try first, is to set-up a script that triggers on scene-open.
You’ll want to register your callback as late as possible. That is, when you can get as much information as possible out of the environment about an artist’s intentions. Typically this would be on scene-open, but could also be when launching the application, or by manually switching task from within a host.
It is in this callback that you either set the
PYBLISHPLUGINPATH or call
Granular file management
The first thing you’ll notice about this technique is that you’ll have to layout your script according to their corresponding task.
At the moment, you may have all of your studios plug-ins in one giant folder. Instead, think of which plug-ins make sense in which tasks, and lay them out accordingly. If you have to register multiple directories for any given task, that is absolutely fine. Prefer keeping your directories as granular as possible, and register as many of them as you can where needed.
For example, you may need some from modeling in rigging. So instead of making a
rigging folder, think about what is common amongst the plug-ins you need shared amongst the two. You may end up with something like
The most clean solution to this that I’ve experienced personally, was a combination of setting up the environment prior to launching a host, and having the ability to alter it from within.
The modification took the form of a dedicated button visualising in which environment you were, such as Shot 1, Spiderman, Animation, along with letting you change any of these on the fly.
As you changed them, any tool you used from that point on, respected the currently set variables.
In this case, it would mean giving Pyblish access to different plug-ins, depending on what you were doing.
This approach is just from my personal experience, and I have no doubt that there is a better, even more capable technique out there. We’ll just have to find it, and when we do, tell everyone about it.