Re: [BuildStream] Migration of plugins away from BuildStream core

[Adam Jones <adam jones codethink co uk>]

Hi all,

On Wed, 2019-02-27 at 10:08 +0000, William Salmon via buildstream-list wrote:

<snip>

Do we really want to remove all of the "normal" sources?

Currently free-desktop loads local and "pip" (badly named more like 

site-pakages) plug-ins. These will still work but it will have to declared 

all the plugins it needs.

It is already hard work to install the extra packages especially in to

things like docker containers.

I thought we were planing on leaving some mechanism to go and get more 

plugins? (whether that is leaving one of these plugins or adding some 

cleaver bit to the bst loading section)

If not, are freedesktop happy about this change to the plan from the 

last gathering?

Removing all the elements/sources from BuildStream itself IMO is not a good idea, however i can see the merit

in not maintaining an ever growing list of git plugins, however removing things like autotools, just seems like more

work for no real benefit, you can already override the default autotools configuration for example.

But as you and Mathieu point out, the proposed change does not come with a solid solution on how projects like

freedesktop-sdk can mitigate this problem

One thing I haven't seen mentioned at all is distribution packaging. I

maintain the Fedora package for Buildstream.

As it is, `dnf install buildstream` on Fedora provides something that

is very useful out of the box.

With the migration, all those plugin repositories will need to be

packaged separately.

I personally do not plan on doing that. I signed up to maintain one

package, and it suddenly transforms into 10+ packages under me, which

is not something I'm happy about.

The feeling at the gathering was very similar for our selves, 

free-desktop already needs external plugins and the Buildstream project

is worried about maintaining a ever growing number of plugins.

There are already a number of different git plug-ins in the wild. To 

better cope with this, the idea behind these changes is for the project.conf

to say which plugins it wants and for bst to do the rest. Hopefully this will

make it easier for new plugins to get brought in to the buildstream eco system.

So the aim hear is to make it easier to maintain more plugins and by not 

having too many as "core" it should encourage "Buildstream" to make 

it as easy as possible to add in extra plugins via project.conf.

In my opinion, If this change results in OS'es needing to package all 

the plugins then this has failed in its original aim.

This point here is exactly the worry i have. It can not be expected for users to install 6/7 different

plugins just to begin working with freedesktop-sdk. If the project.conf has some new way of managing the

installation of plugins then yes this would be a much better solution, but where is that proposed change?

<snip>

Indeed i see this as an opportunity to improve things for freedesktop 

(the main user of bst) by making it easier to install the external plugins,

as users must currently manually install them.

If this is done right, it will improve things like Flatpak and Docker support in the 

future for sure.

Cheers,

Adam