Re: [BuildStream] plugin as elements

[William Salmon <will salmon codethink co uk>]

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