Pyblish workflow manifest

Feature Proposals
#21

that’s a good example. hadn’t considered that.

so before moving on, can i confirm:

  • the config loading prototype i made, makes sense to you. and we now want to expand on that with making this explicit.
  • to expand on this we add datatypes to pyblish, with data to create tooltips and widgets.
  • the config file loading itself has no suggestions for change from you.

If that sounds okay, how about i start on a PR for just string type, to flesh this out.

#22

I’m onboard with the overall idea of having plug-ins draw configuration from an external source; whether that’s a file, a database, environment variables doesn’t matter much and should probably be up to the user.

Having these new String and Bool types be part of pyblish_base seems appropriate. UIs can then be built similar to your prototype, or even Lite and QML, and/or integrated into those too.

The more we can avoid enforcing a particular syntax or schema the better. We can’t fit everyone into one schema anyway. Perhaps the best approach is having the config come from a function and/or plug-in itself. Something that can be programmatically generated, such that those who want a file in some format like JSON can load that file in that function/plug-in.

#23

@BigRoy mentioned openPype has a preset system for plugins, and plugin attributes.
very similar to what’s developped and discussed in this thread

#24

completed: created test plugins

a varied collection of generic pyblish plugins, across dccs.
great for testing several generic setups, and will be usefull to start creating some kind of community pack for each dcc.

some are custom context based, some instance based.

  • instance based plugins can be made to work with plugins from another author more easily, using convertors in between if data type is not the same.
  • custom context ones are more like traditional data driven pyblish behaviour. and are very much locked into their own setup.

did some more work on the manager too:

completed: pipeline configs

  • added support for drag and drop arranging to order plugins
  • delete to remove plugins.
  • now works both in and outside maya
    it’s very easy now to make pipeline workflows, and customise plugin settings if needed.
    been testing this with some of the plugin collections i made and is working quite well.
    image
    image.png1020×436 28.1 KB

next step: convertors.

a validator that needs a pymesh, but the instance is a meshname.
the convertor handles the inbetween stuff.
will try make this as a plugin for now.

this would be the main thing to make community plugins compatible with each other.
i’ve got some pymel and some meshname plugins, that i want to make compatible with each other without simply recoding them.

cool to have: actions browser

It would be cool to be able to add actions to a plugin when creating your workflow.
this would allow actions to be shared in the community/project.
an action could then, just like a plugin, be discovered and registered.

  • but input from actions would need to go through a convertor.
  • and actions cant be saved in a json since they are classes, so we would need to get them from a registered_actions list by name. which now needs to be coded
  • and pyblish base would need to add register_actions functionality.

it’s a lot of steps and not as important right now. let’s get workflows working first.

#25

gave your previous comments some thought

  • to not lock ourself into JSON and support database, file, YAML … we can just keep the whole json pipelineconfig outside of pyblish.
    register_filter already allows a user to add a callback to edit plugins, so supports advanced users.
    the basic TAs and artists can them use some kind of starter pack from another repo which includes this JSON pipeline tool.

  • the custom gui for each plugin is great, but adds extra hassle for the plugin developper.
    ideally writing a plugin is as simple as possible.
    UI for custom options should be optional not needed.
    and the biggest reason: 99% of the time we just want to change basic parameters. a int or string.
    and we know the type of all default plugin attributes already

  • adding the option to adjust external parameters for plugins in QML turns it into an asset validation tool for individual artists.
    but for now i’m focussing on the pipeline aspect for bigger teams.
    options are set in a pipeline config, and then consumed by the user/artist.
    (i know it sound like default pyblish, the main difference is plugins are not unique to project/studio, promoting reusabilty, and lowering barrier to entry to pyblish)

TODO

  • we need a separate options attribute for plugins.
    This is something that ideally goes into Pyblish base. And then in the docs we tell user to put exposed attributes in there.

could do

plugin.options = object()
plugin.options.prefix = "GEO_"
#26

Great work. :partying_face: I’m cautiously optimisting about the idea of “converters”, it does seem like a steep hill to climb. Is node paths the only thing of interest? What about PyMEL attributes or data types like matrices etc? I’ve even heard of some using the MASH Python library, which is apparently a thing.

Plugin data converters
#27

that’s why for now converters are plugins that can be made be the user.
want to support a new datatype? create your own converter
we can have a few basic ones for most common scenarios. now we support 90% of all plugins. the user can make the remaining ones themselves :slight_smile:

easy ones for maya

  • meshname -> pymel mesh
  • transform -> shape
  • meshname -> dagpath
  • short -> long meshname

if there are any interesting checks on github that are worth creating plugins for let me know. would be funto test weird things such as MASH. but think the boring basics take priority for now.

most stuff i find is either meshname(cmds) openmaya and pymel which is easy to convert to each other.

Plugin data converters