Proposal to add options to a plugin

Proposal to add options to a plugin

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.

needs for options also mentioned here

and original thread with marcus

also do we want to support dynamically adjusting options?
and different options between 2 times the same plugins?
think we can ignore these for now.

reading through some other threads and found that Pyblish already has something like this.
but only for instances and context
options can be set through the data:["isAwesome"] = True


adding this same setup to plugins could work for now.


it appears data suffers from the same problem as overriding class variables.
you don’t know what’s already in data

a user who write a plugin to collect a mesh by name might make an option “name”
but context already contains the word “name”

class Instance(AbstractEntity):
    def __init__(self, name, parent=None, **kwargs):
        super(Instance, self).__init__(name, parent)
        self._data["family"] = "default"
        self._data["name"] = name