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

[Angelos Evripiotis <angelos evripiotis gmail com>]

On Sun, Apr 14, 2019 at 11:39 AM Tristan Van Berkom
<tristan vanberkom codethink co uk> wrote:
> If we can get some prototype which demonstrates the base concept of:
>
>   * Installing two separate venvs with different dependency versions
>   * Running an interpretor which loads a plugin in both separate
>     venvs (it could even be the same plugin, and need not be a
>     "BuildStream" plugin, but some python module loaded on demand)
>   * Prove that we infact have separation (perhaps by having the plugin
>     just print the versions of it's dependencies).

I've been looking at this today, it hasn't come together in the easy
way I was hoping for :)

I'll spend some time on it again tomorrow; I'm now less optimistic though.

If it does come together, I expect some limitations to prevent inconsistencies:

- BuildStream and the plugins should probably only use standard
library and BuildStream types when calling eachother. This is to avoid
confusion around mismatched versions.
- We'll need to wrap calls from BuildStream to plugins with something
that intercepts inline imports. e.g. like a pluginbase.PluginSource
context.
- Plugins should only use public API functions to call eachother, so
we can intercept inlined imports correctly. Alternatively we can
introduce proxy objects that do it. Alternatively inline importing
could be banned, I doubt this would be workable though.

Cheers,
Angelos