> > 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 >
