On 26/06/2020 09:52, Benjamin Schubert wrote: > > I think we should be closing the API to prevent writing in the sandbox, but I > think we need other construct beforehand, and to rethink how impacted plugins > actually should work in BuildStream.
+1 > > The aim is to more specifically remove the `Directory.open_files()` call for > writing files in the directory. Is that accurate? Or is there more things that > would disappear? It seems like there's been quite a bit of churn on api and that's resulted in porting work for plugins and projects needing them. Is it fair to say that some of this is from uncertainty/disagreement about api design? Are there any process changes that can be made to better formalize and enforce acceptable api attributes? > > I do agree that we should do our best to prevent plugin authors from shooting > themselves in the foot and to help them achieve the most repeatable build > possible. However I don't think there is a difference between trusting Python > for us, and trusting python for the plugins. That is true but it's also about how and in what stage the artifacts can change right? This is related to the question above about formal requirements for api. Ultimately, there's clearly desire for plugins that do these sorts of things and so developers will find a way to do it regardless which can lead to project fragmentation or rejection. I think it's better to find a practical compromise. > > The second part would then be, for plugins that are 'packaging', like docker > or > oci, to rewrite the element to work on the `artifact` source instead. And for > other elements, like `bazelize`, to actually be a `SourceTransform` based on > the previous elements. But does that resolve the original state problem or just defer it to another element? -- Best Regards, Darius For Codethink's privacy-policy please see https://www.codethink.co.uk/privacy.html
