Third party plugin sharing
Currently BuildStream supports either it's own privately installed plugins or any plugins a user includes in their project.
It's possible to share plugins by way of revisioning your project with git and sharing plugins using git submodules, but that's not a nice way of doing this (lets face it, people wont do it).
Also, in order to mitigate the risk that comes with merging new code too quickly, it would be nice to have a place for plugins to live before putting them in the buildstream repository itself.
One question arises which is whether we want to support namespacing of plugins now that we have some context of a "package", we can potentially allow multiple packages to contain overlapping plugin names and it would mean you would need to name your elements as kind: ${package}_${kind} or such.
Another question is whether we want to unconditionally load them, or drive that with some semantic. Perhaps it's fine if 2 packages provide a foo element, when the onus is on the user to decide which of those two packages they want to use explicitly in their project.conf ?
This will essentially involve:
- Defining what is a plugin package and how packages are discovered
- Loading the packages at load time (our loader currently loads all the python files in a directory as separate plugins, so this should just be the same but on a package directory)
- Documenting how plugin packages are installed
- Creating a buildstream-extra repository or such to hold plugin packages