Hi Chandan,
On Thu, 2020-10-01 at 21:15 +0100, Chandan Singh wrote:
> Hi,
[...]
> > having a documented, single point of entry, way to call scripts that
> > "extends" buildstream in a certain way keeps things together.
> > even if the code that calls the scripts is just:
> >
> > subprocess.call([..bst_script_args])
>
> Not sure if I understand this either. Whatever the script is called,
> you would need to know how it works before calling it. So, how is
> calling `bst helper-script` different from `bst-helper-script`?
>
> Also, the apparent unified syntax would end beyond discovering the
> script name. For example, there is no way for BuildStream to enforce
> or even know that all these scripts would be accepting similar CLI
> options, flags etc. I think this discovery mechanism gives a false
> sense of uniformity, where it isn't there.
I tend to agree that this proposal does not add much in terms of a
technical solution to the social problem more widely discussed in our
parallel thread about hosting plugins and extensions[0].
I do tend to think that having something like this would be better than
the nothing we currently have, i.e.:
* BuildStream could install a `buildstream.pc` file, and dependent
extension scripts could use this at install in
"the extension directory" which is dictated at BuildStream
configure and install time on the host (possibly BuildStream's
own "${pkgdatadir}/extensions" would be a good place).
* Having an extension listing mechanism and a way to launch an
extension would incentivize extensions to properly use the
pkg-config file we would install and follow some guidelines
about how/where an extension script is to be installed on
the system.
Having this simply in place would provide a slightly more pleasant
experience to users in terms of discoverability. We would have a
`list-extensions` command show up in `bst --help` and a way to show
extension help, more learnable than `bst-<tab>`.
More interestingly than this, it would provide a better answer to
developers who's initial instinct is to try to add features directly to
BuildStream (admittedly I hold this more close to heart) - for a well
meaning developer who wants her feature in BuildStream, it's annoying
that we have to answer "Just write a wrapper script", which sounds a
lot like "leave me alone, I'm not interested".
In truth, I want them to leave us alone, and I'm very uninterested in
adding anything to the core which can be accomplished with a wrapper
script, but the entire process of telling people to leave us alone
would be so much more pleasant if we had a nice story to tell about how
extension scripts "are a thing", and how to properly install them so
that their help output will be reachable in `bst --help`, and to tell
them where they can open an issue to add a link to their own tool's
documentation in the "extensions" section of our user docs.
I'm personally on the fence about the technical approach, but I really
would like to have the social problem solved (any other ideas than this
one to choose from ?).
Maybe it would be more interesting if we had public Stream() object and
some kind of plugin interface for our frontend to load the extension
and allow it to run sessions through Stream(), but I also don't want
those interfaces to be public for a long time (at *least* not before
2.0 has been out for a while)... but maybe we could start with
something simple like this, just to satisfy the social problem, and
offer something more plugin-ish at a future date.
Cheers,
-Tristan
[0]:
https://lists.apache.org/thread.html/rebcb1928cc8e61d05a696218967cf5a451ce053454472478067d64a4%40%3Cdev.buildstream.apache.org%3E
