Proposal to add options to a plugin

[hannes]

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.

proposal

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_"

type

Pyblish workflow manifest

The problem I have with overwriting class members is that it’s not clear which is meant to be overridden and what is not, along with there not being enough information to implicitly derive metadata from just a single value. For example, should that string be a regex, can it contain unicode, and especially numbers which often have min and max limits.

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.

[hannes]

needs for options also mentioned here

Options for plugins

Hi, I want the extractors to have some options. E.g. as in Pyblish-magenta ExtractAlembic, it has a few options like noNormals, that the user may want to set. After some research I found these links. Pyblish Search and Customisation - where @marcus talks about the option system, but I don’t see this implemented in pyblish. Custom UI prototype - the ftrack approach, which is kinda what I want, but they are using a custom UI. User Fields in Pyblish QML - which is exactly what I need, but se…

and original thread with marcus

Pyblish workflow manifest

Ok, I see what you mean. So instead of the data being explicitly created and accessed, it can rely on data being created and accessed like family and label and other class variables already are being created. And then this tool would load the plug-in, overwrite those values… ValidateFilePaths.pattern_name = "Something_else*.ma" …followed by re-loading the plug-in instance directly via e.g. api.register_plugin(modified_plugin) Personally, I think we could take it one step further. class Va…

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.

[hannes]

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:
context.data["isAwesome"] = True

docs

adding this same setup to plugins could work for now.

issues

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
        self._data.update(kwargs)