To be able to share larger parts of a pipeline without compromising flexibility.
Motivation
Pyblish and Avalon are great frameworks to share between pipelines, but they only share very common tools whereas the majority of a pipeline consists of plugins within configs (?). This means there are potentially doubling workloads, when two configs output the same data but with different plugins.
An example would be that pype-config shares the same/similar plugins with colobleed, but they are two different repository without any knowledge or code exchange. The reason for having two different configs is because of different client requirements, so the two configs can't be merged into one repository.
What can be shared between the two configs are individual plugins, so why are the plugins not shared?
This comes down to a management issue, which would be great to discuss as the potential knowledge exchange would be massive.
Implementation
The first place to look for sharing of plugins would be within the Pyblish framework. The majority of code are with Pyblish plugins and getting a consistent output of data between pipelines could align input and workflows eventually.
Though it would be interesting to discuss sharing other plugins with Avalon as well.
Current tools for sharing plugins are maybe git submodules, but you end up having to manage which plugins to load and which work together.
An idea to better manage this would be to turn Pyblish into more of a data-flow graph, where you could pick with plugins or graphs of plugins to load. Both plugins and graphs would be shareable, so a pipeline could remain flexible to unique client requirements but share non-unique code.
Goal
To be able to share larger parts of a pipeline without compromising flexibility.
Motivation
Pyblish and Avalon are great frameworks to share between pipelines, but they only share very common tools whereas the majority of a pipeline consists of plugins within configs (?). This means there are potentially doubling workloads, when two configs output the same data but with different plugins.
An example would be that pype-config shares the same/similar plugins with colobleed, but they are two different repository without any knowledge or code exchange. The reason for having two different configs is because of different client requirements, so the two configs can't be merged into one repository.
What can be shared between the two configs are individual plugins, so why are the plugins not shared? This comes down to a management issue, which would be great to discuss as the potential knowledge exchange would be massive.
Implementation
The first place to look for sharing of plugins would be within the Pyblish framework. The majority of code are with Pyblish plugins and getting a consistent output of data between pipelines could align input and workflows eventually. Though it would be interesting to discuss sharing other plugins with Avalon as well.
Current tools for sharing plugins are maybe git submodules, but you end up having to manage which plugins to load and which work together.
An idea to better manage this would be to turn Pyblish into more of a data-flow graph, where you could pick with plugins or graphs of plugins to load. Both plugins and graphs would be shareable, so a pipeline could remain flexible to unique client requirements but share non-unique code.