Bringing in some related topics for completeness.
Each are related to dynamically altering the available plug-ins at run-time. Perhaps we can find a uniform solution for each. At the moment, they each propose unique solutions that, in a way, achieve a similar goal.
Let's address the scenarios first.
This kind of flexibility is actually why
Prior to launching any process, you have access to the full environment of the workstation - like user, current project, task, time, hardware specs etc. This should provide you with enough information to make a decision about what features (i.e. plug-ins) to include.
# Register paths before launching software.
os.environ["PYBLISHPLUGINPATH"] = "/my/plugins/%s" % getpass.getuser()
Run-time is for when you require access to additional information only available from within a process. It's intended primarily for advanced/esoteric and debugging cases.
# Register paths at run-time
has_renderlayers = True if maya.cmds.ls(type="renderLayer") else False
"/my/plugins" + "/render" if has_renderlayers else "")
At each point, a decision is made using the available information about which plug-ins to include. This proposal would allow this decision to also be made after
Selection has finished, is that right?
Yes, that's right, this doesn't work for you?
Would it be possible to determine whether a host is ftrack-aware during startup or at run-time?
Example 1 in studio X, everyone uses ftrack. So I know that it is safe to make ftrack-assumptions in all of my plug-ins. In this case, plug-ins don't require a
has_data but can instead assert that it exists, resulting in appropriate result in the GUI.
Example 2 during start of a process via the ftrack launcher, would it be possible to register ftrack-related plug-ins then? In this case, plug-ins can still assert the existence of ftrack-related data, as ftrack-plugins are only loaded when they are supported, as guaranteed by the launcher, resulting in appropriate results in the GUI.
Example 3 the launcher decides whether or not ftrack is available, but only a subset of all families are meant for processing by it. In this case, maybe we could utilise the family registration from this thread to inform the extension about which families to process? The end result is what we would expect in the GUI.