Re: [BuildStream] Thoughts around plugins (Too long, please read carefully)

[Daniel Silverstone <daniel silverstone codethink co uk>]

On Thu, Nov 22, 2018 at 16:27:40 +0000, Sander Striker via BuildStream-list wrote:
> > I agree, and frankly I'd be completely happy to move away from "pip" and
> > just
> > leave local plugins which must be below the project core, encouraging the
> > use
> > of submodules or svn:external or however someone is storing their project.
>
> git submodules and svn:external are both well know for their user
> friendliness...

They're not glorious, but at the same time, they're far easier to *track and
trace* than arbitrary pip'd stuff.

[snip]
> Maintaining such an index _well_ is also significant effort, and has the
> potential for similar scaling properties.

Indeed.

> > One alternative to submodules could be to include a repo URI and ref in the
> > plugin stanza in the project.conf though, and let BuildStream go ahead and
> > fetch the plugin.  I think it's entirely up to the plugin to be sensible
> > and alter its input into the cache key if it changes incompatibly though.
>
> The cache keys part is fairly crucial.  I understand Tristan's thought
> here, the only way to be truly sure about artifacts is to capture all the
> inputs in the cachekey.  And here a plugin is an input.  That does lead to
> the problem of instantly invalidating caches when a plugin gets updated (or
> at least double storage requirements).
> Where do we put the trust here?  Do we capture the plugin version and
> potentially checksums in the artifact provenance, so that we at least know
> what version of a plugin an artifact was produced with?  Or are we not
> trusting at all, and do we invalidate caches, potentially more than
> desirable?

If we go down the "Only local plugins" route, or even "Only plugins loaded
from a Source we can 'track'" then I don't think we need to capture the plugin
content itself, save for being able to rebuild from an artifact if that's
a desirable thing.

If plugins weren't arbitrary python code, we'd stand a chance of including
them in the cache key, but it's simply not viable to rely on anything which
isn't a developer stating compatibility/reproducibility markers e.g. via
a FORMAT_VERSION type thing which we currently have.

D.

-- 
Daniel Silverstone                          https://www.codethink.co.uk/
Solutions Architect               GPG 4096/R Key Id: 3CCE BABE 206C 3B69