| juergbi | tristan: we already allow plugins to add files with content directly. this has already been used before virtual directories in multiple element plugins, e.g., manifest and docker/oci image creation | 04:36 |
|---|---|---|
| juergbi | I would also prefer doing as much as possible in sandboxed commands and keeping the plugins very simple | 04:40 |
| juergbi | however, we don't even try enforcing anything like that right now. if you want to suggest changing that, we'll need a larger (ML) discussion. and it might require some non-trivial plugin porting | 04:48 |
| tristan | juergbi, I think the plugins in freedesktop-sdk which do this nonsense are buggy as hell and I don't think they should be considered a model citizen | 08:46 |
| tristan | The fact that they write manifests in python code, is definitely 100% a bug IMO | 08:47 |
| tristan | The fact that they crawl the dependency tree and make assumptions that they can call API on those plugins beyond Element and Source defined API, is unquestionably a bug | 08:47 |
| tristan | I dont know that it is up to us to support porting of those plugins either | 08:48 |
| tristan | If they went ahead and employed hacks to get something done instead of properly communicating a need to us, and getting something implemented in core if they need that, that should not be our problem | 08:49 |
| tristan | We should not be blocked on buggy plugins doing wrong stuff | 08:49 |
| tristan | juergbi, The only thing we *could* really try doing to enforce it, is to change plugin code to something like starlark, or any formalism which *ensures* people dont use API which we do not provide | 08:50 |
| tristan | But I think that providing API that people clearly should not be using anyway, is definitely a step in the wrong direction | 08:50 |
| tristan | I'd definitely want to make plugins not python, so that people (A) Could not import external python libraries *at all*, and (B) Could not issue any command which BuildStream core does not know about or implement | 08:51 |
| tristan | That is how plugins really should be written anyway, nobody should be calling subprocess directly, or touching files in the sandbox directly | 08:52 |
| tristan | Maybe we didnt write that down anywhere, but I think the design makes it pretty clear that pulling that stuff is simply not allowed | 08:52 |
| tristan | juergbi, if there is a need for an ML discussion, I'll raise one, I don't know why we're talking about it, and what sent us down a path to providing APIs for plugins to do stuff they shouldnt be doing anyway | 08:53 |
| tristan | If you have a link to anything which happened while I was away, sending us down this path, that would help me try to set things straight | 08:53 |
| *** hasebastian has joined #buildstream | 15:05 | |
| *** hasebastian has quit IRC | 17:15 | |
| juergbi | tristan: crawling the dependency tree and calling plugin-specific methods guessed to be available based on 'kind' I consider a bug as well, however, that's more or less orthogonal to direct filesystem manipulation, which was the topic | 19:16 |
| juergbi | Sandbox.get_directory() has existed from early on, allowing direct filesystem manipulation. if we didn't want direct access, why expose the path at all? | 19:17 |
| juergbi | that's now replaced with the virtual directory API but it's pretty much the same when comparing what plugins can do | 19:18 |
| juergbi | we could theoretically completely remove direct access to the (virtual) directory from the public plugin/sandbox API, forcing everything to be done by sandbox commands | 19:21 |
| juergbi | however, that would be a big change for some plugins and we need to be sure plugins can be ported in a reasonable way | 19:22 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!