Options for plugins

asztalosdani · February 23, 2018, 2:59pm

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 seems unfinished.

So I want to set options for plugins in context and per instance (I want to export normals for Bob, but not for Alice) and I want to use the pyblish-qml as gui. How should I do that?

One thing comes to my mind. Create a preprocess gui before starting pyblish. It would show the options, and set them in the scene (maybe on the export set), then launch the pyblish-qml. But it would mean, my preprocessor gui should run the collectors, and also gather all the VEI plugins to show their options. Then we are just one step away from rewriting the whole pyblish gui, which is not what I want.
Unless you tell me, there is no other way…

tokejepsen · February 23, 2018, 3:20pm

There is currently nothing like this for Pyblish. As you said it has been discussed before and would be very welcome addition to Pyblish-QML (hint )

I have been using custom attributes in Maya and Nuke when users wanted customization over the submission/publish. It has worked where a validator and action ensured the existence of the attributes, which the user would then go back and customize.
Not ideal so a solution for Pyblish-QML would be great

marcus · February 23, 2018, 3:21pm

Have a look at how Avalon deals with this; in a nutshell, you graphically author instances and set options there. That way, options are picked up during publishing, like any other attribute. The options then are per instance, or family, where they belong. Such as options for a Model, or a Render etc.

https://getavalon.github.io/2.0/tools/#creator

The screenshots are a little out of date, but the practice has worked well.

marcus · February 23, 2018, 3:22pm

Also some more context here

github.com/pyblish/pyblish-base

Plug-in arguments, visualise data

opened 07:33AM - 08 Oct 14 UTC

mottosso

feature

### Goal To facilitate configurable plug-ins in a manner similar to arguments p…rovided to any function or class. ### Architecture The idea is to let data in an instance influence a plug-in. Instances may contain data that affect the operation of a plug-in, similar to how the arguments of a function or method affects it's operation. ![image](https://cloud.githubusercontent.com/assets/2152766/4555161/f1136642-4eb9-11e4-8958-188ce0e385f1.png) The data is then accessible within the plug-in, like this: ``` python class ExtractReview(Extractor): def process_instance(self, instance): assert instance.data('width') == 512 ``` If we document these "arguments" utilising the same syntax used for documenting functions, methods and classes, we can make use of the automated documentation mechanisms of Sphinx along with providing uniform formatting and visualisation of plug-in arguments in our own GUIs. Properly documented, users can know which attributes they can append to their instances in order to affects its output. ### Pure-function example For example, this is how we influence the operation of a function. ``` python >>> extract_review(width=500, height=256) ``` These arguments may be documented in the docstring of a plug-in, similar to regular classes. ``` python def extract_review(width, height): """Extract a review Arguments: width (int): Width of output, in pixels height (int): Height of output, in pixels ``` This style of docstrings is called [Google Napoleon](http://sphinxcontrib-napoleon.readthedocs.org/en/latest/example_google.html) and is supported by Sphinx, the documentation generator. Given this, Sphinx is able to generate nice-looking documentation and formatting. Have a look here, click on "source" to see what it looks like originally. - http://docs.pyblish.com/#discover - http://docs.pyblish.com/#Extractor ### Use in Plug-ins A plug-in doesn't need an **init**, which is where arguments are normally specified when documented in the doc-string. But that doesn't stop us from documenting arguments provided by an instance. ``` python class ExtractReview(Extractor): """Extract as image-sequence (png) Arguments: startFrame (float): Start frame of output endFrame (float): End frame of output width (int): Width of output in pixels ``` Sphinx will then pick this up and produce conveniently formatted documentation, our tools may then also use this information in the GUIs for users to know how to control their publishes. ### GUI Example If plug-ins are documented like this, we could provide helpful information to users in the GUI, so that they know which attributes they have access to, and what they do. ![image](https://cloud.githubusercontent.com/assets/2152766/4555369/bd6c6f3e-4ebc-11e4-97aa-8b5620cc3217.png) ### Non-Maya instances The data available within an instance can come from anywhere, such as directly from a Selector. ``` python class MySelector(Selector): def process_context(self, context): inst = context.create_instance(name='MyInstance') inst.set_data('width', 500) ``` It can also come from any other source, like those available to host-specifics. E.g. Houdini may provide these options through a Digital Asset whereas After Effects may provide them as custom attributes on layers. Or, they can simply be hard-coded into the selector, where the selectors is picked upon start of a host. E.g. starting After Effects may include a particular set of selectors whereas Maya includes others. This workflow is typically called wrappers or boot-strappers.

asztalosdani · February 27, 2018, 8:59am

Thanks for the information!
How would one start working on an issue like this? We would need to discuss further specifications.
I can see two parts of this.

Implement options in the API. The structure in pyblish-magenta’s extract_alembic seems as a good start.
Although we need something for context options and per instance options. (Or do we?)
GUI. And I think this is the bigger part. To my best knowledge, you can’t see plugins collected for individual instances, so this is something that has to be implemented.

marcus · February 27, 2018, 9:15am

Start with a simple prototype. Something standalone, separate from Pyblish, that proves the concept.

Both instances and context have a .data dictionary, which I think is a good place for options. E.g. context.data["isAwesome"] = True
You can, api.discover() will get you all available plug-ins which each have a .families list, and an instance has a corresponding instance.data["families"] list. If these have a shared member, e.g. they both share “model”, then they are meant for each other.