Re: [BuildStream] [Proposal] Plugin fragmentation / Treating Plugins as Sources

[Thomas Coldrick <othko97 gmail com>]

Hi,

On Mon, 2019-04-15 at 13:57 +0100, Adam Coldrick via buildstream-list
wrote:
> This is the current situation, but it feels quite restrictive to
> enforce that requirement on anyone considering writing a plugin in
> the
> future. I don't really have an idea in mind of what kind of plugin
> may
> want to do that, and maybe this assumption is invalid and nobody will
> ever want external dependencies in a new plugin (I'd be interested to
> hear what authors of plugins such as those in bst-external think of
> this, since I don't have a ton of context really).

I've written a couple of plugins, and although none have required
external python modules, I do have a concern that this assumption may
prove invalid. There are two cases I can think of that might go against
the idea that nobody will need external python dependencies:

1. Plugin for a tool with a python API

This is the primary use case I can see - if one is creating a plugin to
handle some tool which provides a python API it would be preferable to
use this API natively inside BuildStream, rather than calling the tool
on the host. In this case using such a plugin requires more pain for
the end user, potentially having to use both the repositories for their
distro and PyPi.

2. Plugin requiring a large amount of custom tooling

This case is a little more vague, but essentially there may be a case
in which someone wants to create a plugin requiring a library of
tooling too large to fit (maintainably) inside of a single plugin file.
While I don't expect this use case often, and it may actually be solved
by using `git` as a source for the plugin anyway, I think it's worth
considering.

As a potential solution, I think it may be better to heavily discourage
usage of the `pip` origin for plugins, but not remove it entirely. To
me the problem caused with bst-external feels like it has more of a
documentation solution than a technical one.

Cheers,

Tom