On Fri, Oct 2, 2020 at 1:59 PM Tomaz Canabrava <[email protected]> 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 > >
