Re: [BuildStream] [Proposal] Plugin fragmentation / Treating Plugins as Sources

[Sander Striker <s striker striker nl>]

Hi,

We seem to be spending a lot of energy on this topic, in particular on a certain aspect.

I'm going to propose we get a bit more incremental here, leaving out a lot of detail as this thread contains too much to quote from.  I would like to refer back to Tristan's proposal when it comes to the detailed description of what the documentation would look like, the break down of plugin domains:

1)  Move _all_ plugins that are not hardwired in (import, filter, junction, ...) out to _one_ external repository.  The documentation would reflect a single location for all the plugins.  Ensure that manually retrieving these plugins and loading them through the plugin local or pip origin works.  

2)  Split the plugins into domain specific repositories.  The documentation will reflect the different categories, and where to retrieve the plugins.    Ensure that manually retrieving these plugins and loading them through the plugin local or pip origin works.

3)  Assess if we need to do anything more at this point.  Does the existing plugin origins solve loading plugins well enough for the time being?  Do we need to evolve the way we load plugins (by adding another origin)?

Obviously I propose this because I have a certain perspective and expectation in terms of the answer to 3.  To me it seems that there are more domain specific issues to tackle for BuildStream.  I think the plugin loading story is much further down the list when it comes to deciding factors of why to start using BuildStream.

Cheers,

Sander