to allow plug-ins to draw configuration from an external source.
without having to rely on the convention of the plugin.
some plugins might read settings from a config.
some might read settings from an ENV var.
if this is hardcoded in the plugin it makes it difficult to reuse plugins,
exposing it publicly allows the TD to control how to load settings.
currently this can be achieved already with the use of public variables, but as you mentioned this could be overriden in the future when pyblish updates.
it could be as simple as adding 1 line to the plugin base class. (pseudo code doesnt work in py2)
plugin.options = object()
then to set options the plugin developper can do
class MyPlugin (pyblish.api.ContextPlugin):
options.offset = 0.5
options.prefix = "GEO_"
problems you highlight
class members cause issues
no good way to get metadata
use said metadata to validate the data, draw widgets, …
we adress overriding class members by using an options variable instead.
if the options variable is a python object, the plugin dev can add getters and setters to it to validate data input. ex an int that needs to be between 1-10, if you set it to 11 an assert raises an exception.
would there be many cases where this is needed though? seems most settings likely are names and numbers.
you mentioned registering settings, to explicitly register type which then could be used with custom GUI widgets.
but this feels like it makes the plugin development more complex.