On Tue, Nov 20, 2018 at 20:00:58 +0900, Tristan Van Berkom via BuildStream-list wrote:
> I won't reply to your whole email right now, but rather since I have
> been thinking a lot about plugins as well lately, I will add some
> insights and ideas to this.
Thanks for taking the time. I'll respond in-line and hopefully this might
encourage some others to take a good look at the whole thread and comment.
> * Project/Core external plugins are currently not very trustable
I was thinking about that the other day. Particularly the pip plugins
make it very hard to know if they'll get hijacked or not.
[snip]
> The advantage of using git submodules to import "local" plugins
> currently is that you always know that you used "exactly this"
> version of an external plugin.
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...
> * One approach I've been thinking of on the back burner is using
> a BuildStream core provided "Source" for the obtaining of plugins.
>
> This approach would have the benefits of using BuildStream fetch
> and track on strictly revisioned external plugins, and also make
> it very easy for users to obtain the plugins (no separate
> installation of plugin packages would be required), it's a bit of
> a rust/crates approach to BuildStream plugins.
>
> The downside of this approach is that project cache keys would
> probably need to be affected by upgrades to external plugin refs.
So while this is a very interesting idea, I think the complexity involved
is high, and the effort required is astronomical and would scale with the
number of plugins which end up being written. It's much safer, IMO, to
provide a kind of lookup site for plugins, but not actually deliver or version
them through that. So, for example, someone might run a putative web search
for "buildstream pijul source plugin" and come to a page on buildstream.build
which explains what it is and where to get it from, along with a suitable
submodule configuration.
Maintaining such an index _well_ is also significant effort, and has the potential for similar scaling properties.
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?
> It's a bit of a pickle because I am worried both that we are imposing
> too much setup time to BuildStream consumers by splitting up core
> plugins (more installation steps), but at the same time we want to have
> plugins which offer clear API revisioning and guarantees which can
> allow project authors to pull in bug fixes and enhancements without
> causing project cache keys to be changed when their upstream plugin
> repositories are trusted.
So long as it's pretty easy to get hold of the main plugins, I think
the setup cost ought to be fairly low.
> Perhaps if we took ownership of how plugins are shared and distributed
> (as opposed to only how they are consumed), we can come up with a
> strategy which does not have either downside ?
As I said above, I fear that taking control of the distribution method might
impose too great a cost on the project. I think the best thing we can do is to
make it lightweight to declare what plugins you want, and then ensure that the
very basic plugins are part of core, but that core can easily help you to
create a project with some known-good plugin sources.
`bst init` could create a project.conf automatically referencing some
buildstream-project important plugins repo which would make the friction low
and also mean that there's a nice example of how to add more plugins to your
project right there from the start.
> This might be an idea that is too far fetched for the near future ?
Not so much far-fetched and over-enthusiastic I think. But not stupid or
impossible, merely high cost.
Now if you want a far-fetched idea, let's talk about my thoughts on replacing
the python-based plugins with a properly safe language along with requiring the
user to authorise the use of any external tooling or internet connectivity
per-plugin :-)
Cheers,
Sander
D.
--
Daniel Silverstone https://www.codethink.co.uk/
Solutions Architect GPG 4096/R Key Id: 3CCE BABE 206C 3B69
_______________________________________________
BuildStream-list mailing list
BuildStream-list gnome org
https://mail.gnome.org/mailman/listinfo/buildstream-list
