Hi Aleix, Abderrahim ... On Wed, 2025-10-22 at 12:09 +0100, Abderrahim Kitouni wrote: > Hi Aleix, > [...] > > It occurs to me, for example, that we can have some elements with a > > -next postfix and these do not abide by the cache key stability rule. > > Once bst 3 is released, the -next elements can be folded back into their > > stable ones and we'll also know we have well-tested elements to release > > instead of doing them all at once. > > I don't think this works. We could certainly do it, but these plugins > would be unusable the same way other plugins in the collection can be > used. So they need to be somehow marked as unstable. > > Instead, we could have these plugins in the community plugins > collection [1] where no such stability rule exists. At the point of > moving to bst 3 (which is probably still very far away), we could take > the opportunity to upgrade the official plugins to the latest. > > We already have an instance of a cargo2 plugin in > buildstream-plugins-community (vs cargo in buildstream-plugins). > Though the reason for the split was different, I think it makes sense > to do something similar in this case. > > What do the others think? >
I think that the prospect of an API breaking "BuildStream 3" is a grim one, and would have to be justified by some design changes (e.g. drop python from plugins avoiding dependency hell, perhaps replacing plugins with a more declarative language and disallowing arbitrary imports, maybe something to learn from bazel's Starlark...) On the one hand, I think adding community plugins is always an acceptable solution. On the other hand... it doesn't provide a correction story from the upstream plugins side. In addition to this, if we were ever to consider a BuildStream 3, we lack a clear way to track down what issues third parties may have worked around in third party plugins (risking that we may repeat the mistake in the future). Looking at https://github.com/apache/buildstream-plugins/pull/93, it seems that this can be worked around for a given project at the project.conf level (however the `make` and `make-install` variables are not namespaced and that may not work). One creative approach which came to mind, would be for buildstream- plugins to provide some include yaml files; allowing projects to apply API breaking fixes at the "overrides" level by simply including a file from project.conf: https://docs.buildstream.build/master/format_project.html#overriding-plugin-defaults Such includes could be versioned, e.g.: ``` (@): buildstream-plugins.bst:includes/enhancements-v1.yml ``` ... possibly using cascading includes where each new "fixes" version includes the previous one. This approach might give us a structured way to track deviations from the default and allow projects to explicitly buy in to the fixes (users remain in control of their API and cache key stability). That is all a bit elaborate, so I'm not sure if we have enough fixes to justify it. As I said at first, an alternative `cmake` plugin from `buildstream- plugins-community` is also fine. Cheers, -Tristan
