Re: [BuildStream] plugin as elements

[Benjamin Schubert <contact benschubert me>]

Hey Will,

I believe my latest proposal and summary [0] would be able to handle everything

Please let us know if you see any problem with the plan.

Ben

[0] https://mail.gnome.org/archives/buildstream-list/2020-May/msg00000.html

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, April 27, 2020 4:25 PM, William Salmon <will salmon codethink co uk> wrote:

> Your proposal sounds rather good but I have not manged to grok all of
> the details the subsequent discussions to tell if this would work for my
> use case although on first reading it sounds idea.
>
> On 24/04/2020 15:48, Benjamin Schubert wrote:
>
> > Hey everyone
> > This is a proposal to allow treating plugins as BuildStream elements.
> > I also propose keeping the `tar` source plugin in core.
> > This was first mentionned in [0], and then in the BST 2 plan
> > as 'Allow accessing plugins across junctions ?' [1]
> > Why ?
>
> The use case that I have been thinking about recently and that is very
> similar to yours but maybe expands it a tiny bit is:
>
> I have a `base` project that is intended to be junction-ed and have some
> elements `depended on` and some files as yml that are meant to be included.
>
> The app/top-level project would always have a junction called bsp.bst
> and this could be changed or have a config option to change what source
> bsp.bst junction-ed.
>
> This seems to work well for many things, eg. filesystem.bst in the
> `top-level` project:
>
>     kind: compose
>
>     (@):
>     - bsp.bst:elements/deploy/filesystem-template.yml
>
>     build-depends:
>        (>):
>
>        - filename: system/userland.bst
>
>
> It would be great if the image.bst in the`top-level` project could be
> something like:
>
>     kind: bsp.bst:plugin-image.bst
>
>     (@):
>     - bsp.bst:elements/deploy/image-template.yml
>
>     build-depends:
>        (>):
>
>        - filename: system/filesystem.bst
>
>
> I can not currently find a way to abstract the kind in to the junction.
>
> This means that many elements can have the above Patten were it is ok to
> have a fixed `kind:` but those like image.bst were different `base`
> projects may want there image.bst to have different kinds are much
> harder to use.
>
> Some `base` projects will have image.bst elements just use a script
> element while others will need custom plugins so it would be really good
> if projects that just want to use a script could have a plugin-image.bst
> that was just a alias to script.
>
> I think your proposal could go a long way to solving this use case and
> maybe even completely solving it. I would be very happy to help out with
> this if it is helping with this use case.
>
> Thanks
> Will