Hi, On Thu, Oct 1, 2020 at 7:03 PM Tomaz Canabrava <[email protected]> wrote: > > On Thu, Oct 1, 2020 at 5:09 PM Chandan Singh <[email protected]> > wrote: > > > Hi, > > > > Apologies for the late response, but I wanted to share my $0.02 on this > > topic. > > > > On Wed, Sep 23, 2020 at 1:09 PM Douglas Winship > > <[email protected]> wrote: > > > > > > +1 > > > > > > I really like this > > > > > > On 23/09/2020 11:19, Tomaz Canabrava wrote: > > > > We know that the code of buildstream should be lean and trimmed down, > > and > > > > that users are expected to create helper scripts that use bst in many > > ways > > > > to achieve different things. Those scripts will probably be shared on > > > > remote repositories and users will look for them, install them, use > > them. > > > > But where are them? How should they look like in the filesystem, and > > how > > > > Buildstream can help us discover what we have installed, with a small > > and > > > > simple command line addition (well, two, really, maybe three): > > > > > > > > bst list-scripts > > > > > > > > lists the scrips installed in /usr/share/bst/scripts and binaries in > > the > > > > form of bst-{script-name} without the `bst-` part. > > > > > > > > so, for instance, if I have: > > > > /usr/share/bst/scripts/license-check.sh > > > > /usr/bin/bst-check-reproducibility.sh > > > > I'd be +0 on this, but if such a command were to exist, I think it > > should at least print the full names and paths in case someone wants > > to investigate. > > > > > > $ bst list-scripts > > > > license-check > > > > check-reproducibility > > > > > > > > $bst l<tab> > > > > $bst license-check > > > > > > > > $bst license-check <args> passes the list of arguments to the script, > > and > > > > executes. > > > > I would be -1 on `bst` CLI auto completing non-bst commands. First, > > `bst` would not know about the options for those commands anyway so > > the auto-complete would only help so much as to discover the command > > names. More importantly, it would give the impression BuildStream owns > > these commands, which would be a bad UX in my opinion. And also has > > the chances to generate more issues for the BuildStream project when > > these third-party scripts stop working, and users are not clear that > > they are not a part of the BuildStream project. > > > > As an alternative, what about just installing all these `bst-*` > > scripts under your PATH somewhere? For example, I have `bst-here` on > > my path and bash happily tab completes it. This way, you could do > > something like: > > > > $ bst-<tab> > > bst-license-check > > bst-check-reproducibility > > ... > > $ bst-license-check > > > > This already works and does not require the `bst` CLI to learn any > > new magic. And it also makes it clear that `bst<space>something` is > > always provided by BuildStream core, and `bst<dash>something` is > > provided by third-party integrations. > > > > I'd be curious to hear what would be the upsides of having `bst` > > itself do this rather than rely on standard bash completion. > > > nothing besides a single entry point to discover what are the scripts that > are supposed to be used with buildstream. > when you say "this already works" you are relying on people making sensible > choices - we know that people will not do sensible choices. > a $random company will do company-name-buildstream-something.sh , another > will do clear-bst-tree.sh, and so on.
I'm not sure if I follow this line of argument. You are claiming that people can't be trusted to put `bst-` in front of their scripts, but they can be trusted to put their scripts in `/usr/share/bst/scripts`? I would think that it is equally, if not more, likely that a "random company" would put things inside /opt/random/share/scripts etc. In fact, your original proposal mentions stripping of the `bst-` prefix so if the scripts aren't named this way, your proposal won't discover them either. > 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. Best, Chandan
