Hi Martín,
Sorry for the late follow up...
On Thu, 2024-11-21 at 15:04 -0300, Martín Abente Lahaye wrote:
> Hello again,
>
[...]
> Up until now, tools have been developed to extend BuildStream
> capabilities or to integrate BuildStream with complementary systems
> What do you all think about the problem presented here and the
> overall idea of opening up these APIs? Think there's a different way
> of achieving the same goal?
>
This has always been "in the cards" so to speak, however we have been
very conservative about making any APIs public over the years, this was
probably a very good choice.
The core is designed in this MVC sort of way very intentionally, partly
because I had considered we may want the freedom to develop multiple
different frontends for the BuildStream core, and partly because it has
just served us well to be strict with this model in order for the
codebase to just "make sense".
Some benefits I can see with surrounding tooling is just the ease of
using Python instead of bash scripts around `bst show`, and also some
optimization where we may have python scripts which can perform
multiple operations on a single loaded pipeline (instead of needing to
load the project multiple times as a consequence of being limited to
`bst show` calls along with other subsequent invokations).
In addition to the core APIs you propose, we would probably want to
make public some of the BuildStream frontend APIs, so that scripts can
load the App/Stream for a given purpose and still have logging work in
a consistent way, or, perhaps this would "just work" as a function of
using the App object.
Another thing to consider is what compatibility guarantees can we make
with a public facing python library for frontend scripts to invoke,
will it be more difficult to ensure that the frontend scripts you write
now, still work with versions of buildstream in 5 or 10 years time ?
Considering subtle breakages in new Python releases, I expect this new
API surface to be slightly more breaking than what we've seen with
plugins so far (which are thankfully more restrictive and hopefully
dont do crazy things like importing rogue modules not part of the
standard python library).
Overall all I can say is that I don't object, I think we want to remain
very conservative and paranoid about any APIs we make public in this
way, we want to keep the code consistent in the ways in which we
communicate public-ness of functions, I would hope that we are very
picky about reviewing such a large change.
Cheers,
-Tristan
