Originally posted by Marcus on Google Groups.
I’m thinking we make a separation between what is an integration and what is an extension. Here is how I’m thinking.
Pyblish for Maya integrates Maya with Pyblish via the file-menu item. Eventually, it will also provide the implementation that communicates with the GUI.
It also provides a few plug-ins. These plugins extend Pyblish in a way specific to Maya, but also specific to a particular way of working. I.e. it requires users to add nodes to an objectSet and that they append certain attributes.
If we refer to the menu-item and GUI integration stay as an integration of Pyblish, we could refer to the plugins themselves as an extension
The reason I’m thinking we make this separation is because extensions can be added together to form greater functionality. Consider these extensions.
One adds functionality that reports to Asana whilst the other persists metadata onto disk. One is not mutually exclusive, as an integration otherwise would be, but rather augments the main library.
Down the line, I’d like there to be plenty of extensions, but only a few integrations. Taken further, an extension could potentially utilise an integration. Become dependent on it. Such as an extension to Pyblish that utilises the Maya integration.
This could be a workflow extension, with conventions implemented from a particular user or studio. The workflow can then be documented and contributed to like any other project on GitHub. This way we can expose workflows typically only available from within an organisation.
Taken out into the light, it can more easily be perfected, documented and used.
pip provides a features that allows us to create dependencies between packages. For example, installing the pyblish-ilm-rigging could automatically install pyblish and pyblish-maya if it turns out that it was dependent on those. This way, users won’t be bothered with details and can just install whichever extension they would like to try out.