Modules: Allow modules to be customized per project

[BigRoy]

Is your feature request related to a problem? Please describe.

Currently we have settings for the Modules that are system wide, like Ftrack URL and whether Ftrack is enabled or not. However, we are running into the cases where one project might use Ftrack - another might not at all. One project might run one Ftrack url, another might need another.

Would it be possible to implement some (or all?) modules in such a way that they could be project-specific? Or in such a way that'd be trivial for each module to define "project specific settings"?

Describe the solution you'd like

Allow to enable/disable full modules like Ftrack (and upcoming Shotgun, Ftrack, etc.)

Describe alternatives you've considered

For e.g. ftrack it could currently be possible to disable all publish plug-ins in project settings to "reduce" relying on Ftrack but it's been not clearly documented and I believe for a large part untested. Instead we need an approach that from the ground up could allow to enable/disable whether a project runs with Ftrack or Shotgun, and if they do - with which url, etc.

[cuID:OP-5536]

[BigRoy]

class FtrackModule(
    OpenPypeModule,
    ITrayModule,
    IPluginPaths,
    ILaunchHookPaths,
    ISettingsChangeListener
):
    name = "ftrack"

    def initialize(self, settings):
        ftrack_settings = settings[self.name]

        # Module enabled
        self.enabled = ftrack_settings["enabled"]

        # Project enabled
        if self.enabled:
            project_name = os.environ.get("AVALON_PROJECT")
            if project_name:
                project_settings = get_project_settings(project_name)
                if not project_settings["ftrack"]["enabled"]:
                    self.enabled = False

If I change the top of the Ftrack module to this and add an enabled checkbox to the ftrack in project settings what issues might I face? I was hoping by doing that I'd at least avoid all pyblish plug-ins being available and thus killing 99% of the functionality. Tray would still initialize it since it launches without a project, right?

It would look like this in Project Settings:

It would act as a local override to disable ftrack for that project. It wouldn't ever set it enabled for just a single project if the module itself wasn't enabled in System Settings to begin with.

[antirotor]

We have the same issue in AYON and I think having ftrack/shotgrid module per project is indeed necessary.

[mkolar]

We've already done this to a small degree with ftrack, to be abel to turn it off in AYON, howeverm we need a proper solution.

Having bundles actually offers a built in option to do this though provided we adjust how we're launching applications. Technically what would need to happen is.

1. Allow assigning a bundle to a project (optional, use production if nothing is explicitly assigned)
2. Improve Launcher CLI to easily allow passing it context and application, which would in turn lauch with those constraints. Voila. You have just started a DCC with a different bundle, hence completely different set of addons.

Both 1 and 2 are on the roadmap for AYON

[BigRoy]

Still relevant to AYON - but not sure if we want to track on ayon-core. Will let @dee-ynput and @mkolar decide how to push this forward?

[iLLiCiTiT]

Closing this issue for now. It is still relevant, but at this moment ayon-core is not first class citizen.