Hi Tristan, On Fri, Oct 2, 2020 at 5:42 AM Tristan Van Berkom <[email protected]> wrote: > > 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 am personally not too keen on extensions being part of `bst --help`. This leads to the same problem that git extensions like hub create, that it is not clear to end users what features are offered by BuildStream and which are extensions. For example, if `bst-random-script` breaks for whatever reason, I'd like all the issues to be reported to the bst-random-script repository. But if the command is instead `bst random-script`, it is natural for users to expect to report it to BuildStream. And maybe also leave with a bad taste in mouth that BuildStream CLI is not stable. So, unless we can make it absolutely clear that some things are core BuildStream features and others are extensions that may break at any time without BuildStream being able to do anything about, I would be skeptical of adding those extensions in bst help output. > 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 > >
