You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@buildstream.apache.org by Chandan Singh <ch...@chandansingh.net> on 2020/10/01 16:08:43 UTC
Re: Proposal: Enchance discoverability of buildstream helper scripts
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
<do...@codethink.co.uk> 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.
Cheers,
Chandan
Re: Proposal: Enchance discoverability of buildstream helper scripts
Posted by Douglas Winship <do...@codethink.co.uk>.
On 01/10/2020 17:08, Chandan Singh 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
> <do...@codethink.co.uk> 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.
>
+1
I agree with everything here about the tab completion.
bst<dash> is a good naming convention to use here. bst_license_checker
doesn't follow it at the moment, but could probably be renamed if we
decide it's important for everything to match.
>
> Cheers,
> Chandan
>
Re: Proposal: Enchance discoverability of buildstream helper scripts
Posted by Chandan Singh <ch...@chandansingh.net>.
On Fri, Oct 2, 2020 at 1:59 PM Tomaz Canabrava <tc...@kde.org> wrote:
>
> >
> > 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`?
> >
>
> Kinda. Let's exemplify with the git tooling as I think git tooling does
> an amazing job at this.
Personally, I disagree. I think git's choices make it difficult to
find which are core git commands, and which are extensions. I believe
it is important to have that distinction so that users can know which
things BuildStream can guarantee and which things BuildStream can't.
Since the CLI is our only user-facing interface, we have to be
extremely careful in not giving the impression that
`bst-random-script` is something that BuildStream supports, or can
guarantee stability of.
> When you want to look what git does, you do a git help.
> That will tell you:
>
> examine the history and state (see also: git help revisions)
> bisect Use binary search to find the commit that introduced a
> bug
> diff Show changes between commits, commit and working tree,
> etc
> grep Print lines matching a pattern
> log Show commit logs
> show Show various types of objects
> status Show the working tree status
>
>
> Nice, so we know how that git offers those commands, a find / -name
> "git-bisect" tells me that all of them are in /usr/bin/git-core
> ls -l inside of /usr/bin/git-core tells me that some of them are soft links
> to /usr/bin/git - probably some special handling on the git binary,
> so I'll not look at those. git-bisect on the other hand is a simple script
> - like the ones we are talking about for buildstream.
>
> doing git bisect --help is the same thing as doing git-bisect --help - if
> that git folder is exported as PATH, why would anyone want
> to use a separated folder for specific git tooling?
>
> - Because the separation from the standard folders makes it easier to
> manually install / uninstall without breaking the whole system
> - Because it offers a simple and unified way for git to know what are the
> helper scripts that are supposed to be used with git.
> - Because it offers the new user a consistent way to discover what git has
> to offer
> - Because you don't need to remember the name of all of the installed
> scripts (git help will tell you them, as bst help could also do)
>
> I would think that it is equally, if not more, likely that a "random
> > company" would put things inside /opt/random/share/scripts etc.
> >
>
> That doesn't happens with git, the tool that I'm using as comparisson.
I'm not sure what you mean. It requires effort by the package
maintainer to put git extensions in the right place. If they are not
willing to cooperate it would definitely not work. And if they are
willing to cooperate, I'd assume prefixing the script with `bst-` is a
smaller ask.
> > 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.
> >
>
> True, my proposal was a call for discussion, not a formal proposal, I was
> brainstorming while writting because I think the current status is not good.
Okay, I will wait for a proposal then.
> > > 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`?
> >
>
> The difference is that I can use `bst list-scripts` or `bst help` or any
> other
> command line option that we agree on to list the scripts while also
> providing
> a small text with explanation on the side, by running `sript-name
> --one-line-explanation` or similar.
Again, there's no way for BuildStream to know or enforce this.
> 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.
> >
>
> There isnt there *yet*. Thing is, do we want a easy way for users to
> discover what are the
> "extensions pack" currently installed that work with buildstream?
I think we need to be clear what problem we are solving. Is this
specifically for people who have installed a bunch of bst extensions
and have forgotten that they have them installed? If they have not
installed them in the first place, the discovery would actually
involve writing better documentation and pointing people towards what
extensions exist.
> I need to say one thing too - The unix tooling is growing a lot, and many
> new users are just discovering what we have to offer - because of Azure,
> because of DigitalOcean, because of AWS.
> making it easy for non-sysadmins and lowering the entry barrier for
> wannabe-devops, wannabe-sysadmins, is something that we should consider.
>
> Best,
> Tomaz
>
> Best,
> > Chandan
> >
Re: Proposal: Enchance discoverability of buildstream helper scripts
Posted by Tomaz Canabrava <tc...@kde.org>.
>
> 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`?
>
Kinda. Let's exemplify with the git tooling as I think git tooling does
an amazing job at this.
When you want to look what git does, you do a git help.
That will tell you:
examine the history and state (see also: git help revisions)
bisect Use binary search to find the commit that introduced a
bug
diff Show changes between commits, commit and working tree,
etc
grep Print lines matching a pattern
log Show commit logs
show Show various types of objects
status Show the working tree status
Nice, so we know how that git offers those commands, a find / -name
"git-bisect" tells me that all of them are in /usr/bin/git-core
ls -l inside of /usr/bin/git-core tells me that some of them are soft links
to /usr/bin/git - probably some special handling on the git binary,
so I'll not look at those. git-bisect on the other hand is a simple script
- like the ones we are talking about for buildstream.
doing git bisect --help is the same thing as doing git-bisect --help - if
that git folder is exported as PATH, why would anyone want
to use a separated folder for specific git tooling?
- Because the separation from the standard folders makes it easier to
manually install / uninstall without breaking the whole system
- Because it offers a simple and unified way for git to know what are the
helper scripts that are supposed to be used with git.
- Because it offers the new user a consistent way to discover what git has
to offer
- Because you don't need to remember the name of all of the installed
scripts (git help will tell you them, as bst help could also do)
I would think that it is equally, if not more, likely that a "random
> company" would put things inside /opt/random/share/scripts etc.
>
That doesn't happens with git, the tool that I'm using as comparisson.
> 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.
>
True, my proposal was a call for discussion, not a formal proposal, I was
brainstorming while writting because I think the current status is not good.
>
> > 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`?
>
The difference is that I can use `bst list-scripts` or `bst help` or any
other
command line option that we agree on to list the scripts while also
providing
a small text with explanation on the side, by running `sript-name
--one-line-explanation` or similar.
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.
>
There isnt there *yet*. Thing is, do we want a easy way for users to
discover what are the
"extensions pack" currently installed that work with buildstream?
I need to say one thing too - The unix tooling is growing a lot, and many
new users are just discovering what we have to offer - because of Azure,
because of DigitalOcean, because of AWS.
making it easy for non-sysadmins and lowering the entry barrier for
wannabe-devops, wannabe-sysadmins, is something that we should consider.
Best,
Tomaz
Best,
> Chandan
>
Re: Proposal: Enchance discoverability of buildstream helper scripts
Posted by Chandan Singh <ch...@chandansingh.net>.
Hi Tristan,
On Fri, Oct 2, 2020 at 5:42 AM Tristan Van Berkom
<tr...@codethink.co.uk> 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
>
>
Re: Proposal: Enchance discoverability of buildstream helper scripts
Posted by Tristan Van Berkom <tr...@codethink.co.uk>.
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
Re: Proposal: Enchance discoverability of buildstream helper scripts
Posted by Chandan Singh <ch...@chandansingh.net>.
Hi,
On Thu, Oct 1, 2020 at 7:03 PM Tomaz Canabrava <tc...@kde.org> wrote:
>
> On Thu, Oct 1, 2020 at 5:09 PM Chandan Singh <ch...@chandansingh.net>
> 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
> > <do...@codethink.co.uk> 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
Re: Proposal: Enchance discoverability of buildstream helper scripts
Posted by Tomaz Canabrava <tc...@kde.org>.
On Thu, Oct 1, 2020 at 5:09 PM Chandan Singh <ch...@chandansingh.net>
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
> <do...@codethink.co.uk> 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
>