Plugin settings overrides

[iLLiCiTiT]

Description

We should be able easily apply attribute value changes for all plugins (pyblish, load, create, ...) from settings. Which probably does not work as expected in all cases right now. That is because some plugins may be registered from pype modules but settings are looking only into host specific settings.

Right now it maybe work as expected for pyblish plugins if folder structer match settings structure. Which is nice but also not 100% as it is based on filepath of dynamically loaded modulu which may not contain correct in all hosts as every python may have different approach how to load plugin files.

Suggested solution 1

All plugin class names would be unique across all modules/hosts so it would be possible to load all plugin specific settings from all project specific settings and get the value/s by class name. Big disadvantage is that we must be carefull about plugin names across whole pype.

Suggested solution 2

Implement class method on each plugin type class that would change class attributes based on passed project settings value. This method can be implemented on Pype's plugin class which would be used as base for plugins. This method can do what is happening in current patched_discover function. This approach gives more freedom as it would be easy to change content of the method for specific cases where it is easier to use different values that plugin specific.

# Example
# This class can be used as base for all publish context plugins so all plugins would work the same way.
class PypeContextPlugin(pyblish.api.ContextPlugin):
    @classmethod
    def apply_settings_overrides(cls, project_settings):
        # Code from `patched_discover`
        filepath = os.path.normpath(inspect.getsourcefile(cls))
        host_from_file = file.split(os.path.sep)[-4:-3][0]
        plugin_kind = file.split(os.path.sep)[-2:-1][0]
        config_data = (
            project_settings
            .get(host_from_file, {})
            .get(plugin_kind, {})
            .get(plugin.__name__)
        ) or {}
        for key, value in config_data.items():
            setattr(cls, key, value)

This way it can be really specific for the plugin. Also can be easily extended per plugin or globally, like add filters, specify which attributes can be overriden, value validations, totally skip attribute overrides, class definition may specific settings keys where are stored it's values (["ftrack". "publish"]), add ability to change (or set) GUI options by settings etc.

And there are other possible solutions. The point of this issue is to mention that plugin overrides may not work as expected for all kind of plugins in current Pype 3.

[cuID:PYPE-1342]

[mkolar]

I vote for the option 2. There as actually a pseudo version of it in pype 2.x, but it was duplicating the feature of patched_discover I believe

[create-issue-branch[bot]]

Branch feature/1176-plugin-settings-overrides created!

[mkolar]

Considering we're re-working the settings for v4, I would say this is stale now and can be closed. What do you think @iLLiCiTiT ?

[iLLiCiTiT]

It's not related to settings but to how they're applied on plugins. It is still an issue and with addons it will be much bigger issue then it is now.

[hannesdelbeke]

hey, not sure if this is helpfull I created a MVP to apply settings to pyblish plugins after registration. so you can for example choose externally if your tricount validator should check for 5k or 10tris. without having to create new code, inherit the plugin, overwrite settings...

https://github.com/hannesdelbeke/pyblish-plugin-manager

you can see a code sample here https://github.com/hannesdelbeke/pyblish-plugin-manager/blob/main/sample/sample_apply_config.py

it still needs a lot of polish but the basics are there. and will continue developing it.

[iLLiCiTiT]

We have that kind of plugin overrides for a long time. It's in OpenPype settings, but we rather explicitly define what can be changed and what type of value it should be as in some cases it is impossible to define with simple types.

The issue is that they're auto applied based on class name and some folder structure in which they are. That works if the structure is exactly matching settings structure. But it's hitting limits, when you need different structure (e.g. in addons) or use same value in multiple plugins because they're connected.