Byron
universal commandline tool and program launcher
This ticket is four in one actually, but all related.
Problems
universal commandline tool (->UCT)
With bcmd it is already easy to create complex, plugin-based commands whose parsers can form arbitrary trees, and who are truly decoupled from each other thanks to argparse's awsomeness.
In order to prevent everyone to be forced to do her very own thing, it's vital to provide an official place into which to hook in functionality.
It must be highly configurable to allow it to work under any other name as well. Using the standard plugin system, it must be easy to extend it with subcommands.
The context if the command is extremely important, as it defines the startup environment of it. After all, it is likely to be installed in a central and 'blank' location that doesn't do much by itself. It must be extremely easy to adjust the context to the desired one.
As graphical environments are fundamental different in requirements from a standard commandline application, a separately configurable variant of the UCT must exist.
The default UCT should be launched through the standard python interpreter, yet it must be trivially easy to make it launch through another interpreter.
Proposed solutions
the 'be' commandline tool
The tool should be called be for no other reason as that it is easy to type, starts with 'b', and is written like it sounds. It shall be commandline only, without support for graphical interfaces.
Sample usage should be as simple as be [options] {subcommand}, where options are suited to override kvstore variables and set the location of the program.
Subcommands are registered as plugin, which is already easy using existing capabilities of the bprocess package settings.
Example:
# a full launcher invocation,
be @/projects/a ---packages.python.version=2.6 launch
To aid setting the context, the '@DIR' optional argument should change the CWD to the given directory for the entire invocation of be. It is just syntactic surgar for cd DIR && be cmd.
However, the @ Syntax aids platforms where it's difficult to create launchers that invoke a full shell, or that can't set the CWD.
simplified subcommand configuration
For subcommands, it should be easy to pull configuration, possibly from underneath the be commands own settings root. For that, some helpers should be provided.
commandline program launcher
The first be subcommand shall be launch, which allows to launch the given executable. It can list all available executable too. All excess arguments are passed to the launched program.
Usage could look like this
be launch {program,...} [args]
If no program is given, list all available ones.
Documentation
For all tools, make sure to keep an .md file around which describes why the tool exists, and why you want to use it.
To my mind, plenty of information from this issue can go there.
bcmd can now handle chained subcommands automatically, which will greatly improve usability and 'remixability'.
'be' command framework is implemented, was astonishingly simple. After all, it's just a command whose characteristics can be configured via the yaml file.
Still TODO: per sub-command settings. It's trivially done. Think about making this a general facility, that is used used by the 'be' command framework.