On 26/02/2019 11:43, Mathieu Bridon via BuildStream-list wrote:
Hi everyone,
On Tue, 2019-02-26 at 11:07 +0000, Phil Dawson via BuildStream-list
wrote:
# What we want in core
>From various discussions on the mailing list and during the last two
gatherings, this part seems to be fairly uncontroversial. However,
please shout out if you disagree.
The end goal is to have the following plugins in Core:
import
junction
compose
script
junction
filter
manual
local
remote
# The migration of plugins from core
The above list of plugins which we want in BuildStream core leaves
the following plugins to migrate:
elements | sources |
-------------+---------|
make | git |
cmake | tar |
autotools | bzip |
qmake | bzr |
distutils | ostree |
makemaker | patch |
modulebuild | deb |
meson | pip |
pip | |
The plugins which are moved out of BuildStream core will be moved
into use-case specific repositories. While their seems to be general
agreement on this point, the specifics have not had much discussion
and so I'm particularly interested to hear other peoples thoughts
here.
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?
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.
[snip]
Most of the focus of the work to move plugins out of core has up to now,
been on making it easy to test plugins that are not core so that we can
still test them/bst. But the other blocker, in my opinion, to actually
moving plug-ins out of core is that it must be easy for projects to
import plugins, so that users of things like free desktop don't notice
this change.
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.
One of my colleges spent ages yesterday trying to get bst-external to work
in a award/unusual situation, so there is real room for improvement, but
also real risks of things getting significantly worse.
We should not lose sight of the fact that if we end up in a situation were
after the project.conf maintainer has updated the project.conf. If a user
should need to do more than update there project.conf and there version of
buildstream and then let buildstream sort out the plugins then we have gone
backwards.
I got the impression from the gathering that our intention was not to introduce
extra user work to get plugins? I thought we were going to leave a mechanism[1]
to boot strap all the required plugins so that things like bst-external would get
easier to install and that old plugins would not get harder for a user to use.
Will
[1] maybe git but to be agreed by the community and to be introduce at the same
time as we remove the core plugins
