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. 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]) > Cheers, > Chandan >
