Hey Darius, Responses inline
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, 26 June 2020 10:28, Darius Makovsky <[email protected]> wrote: > > > 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? > My point of view on this is: - Much of the API has to change in order to make RE a first class citizen in BuildStream - We had decided when starting BuildStream 2.0 that we would be allowed to break the API in order to move BuildStream in a direction where it would be more performant and better integrated with RE. And the current process requires agreement on the ML, which was not necessarily the case before. I believe that if we stay diligent on that one, we will end up not having too many of them, and only the necessary ones. > > 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. > I think the desire for plugins doing such things can be obtained with different constructs, which we might need to implement and promote, and that "being able to write in the sandbox directory" without running in the sandbox is not a hard requirement for any plugin, if we have a way of doing it differently. Will it mean that plugin authors might not be able to write their plugin the easiest way? Possible, however, that's were as a community we need good examples and documentation on how to do "those special things". > > 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? > Sources have a better tracking of keys and are expected to run outside the sandbox, it is thus easier to handle such things there. Moreover, at least for all the 'packaging' plugins, we would just not need to do anything outside the sandbox anymore. > > ----------------------------------------------------------------------------------------- > > Best Regards, > Darius Hope my answers better clarify my vision, Ben
