Re: [BuildStream] plugin as elements

[Benjamin Schubert <contact benschubert me>]

Hey,

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, 25 April 2020 11:22, Tristan Van Berkom <tristan vanberkom codethink co uk> wrote:

> Hi Benjamin,
>
> Thanks for writing this up :)
>
> Of course I support this feature, I just have some questions and
> possible semantic variance I would suggest.
>
> On Fri, 2020-04-24 at 14:48 +0000, Benjamin Schubert wrote:
>
> [...]
>
> > The plan would be to add a new plugin `origin:`, which would be `bst`.
>
> I think it would be more explicit and fit better into our terminology
> if we called this origin "junction".
>
> This part confuses me, I really don't understand why this loading
> mechanism would require an element.

Right, this proposal is trying to hit two birds with one stone.

The idea of having a `bst element` for a plugin brings a few advantages to the table:

- You can import your plugin from wherever you want instead of having it 'local'
- Possibly more explicit 'patching' mechanism, since you can patch directly the plugin
  instead of having to patch the junction itself
- Plugins authors don't need to maintain an additional project.conf if they don't
  want to (this would still be doable and would still work)

But is also more complex than specifying "use the plugin from this junction".

If this also fit the bill I am fine with implementing it like that.

> I would see this working in such a way that we simply redirect the
> operation of loading plugins to a subproject Project instance.

I don't think it is that simple, if the plugin has defaults that are overriden
by the project, then it will be resolved in the subproject's scope.
Is that what we really want?

> [...]

>     Something which has so far not been discussed is accessibility of
>     plugins we bless and maintain under BuildStream governance.
>
>     I would certainly want to support obtaining blessed plugins using both
>     the `junction` and `pip` plugin origins, giving users the choice as to
>     how they want to obtain them.

I think we can discuss this separately?

>     Cheers,
>     -Tristan

Cheers,
Ben

>     PS:
>
>     Another thing which might be relevant (which applies to all origins
>     equally I think), is that I think it would be interesting one day to
>     extend the plugin origins in project.conf to support "aliases", which
>     would allow statements such as:
>
>     "Load the 'foo' plugin from the 'bar' pip package, and call it 'baz' locally"
>
>     The rationale here is we might one day need two plugins which happen to
>     have a name clash in the same project... I don't think we need this now
>     but I'd like to keep the doors open to that.

As I understand it it would indeed be needed for everything. Let's make a new thread
about it?