There has been a silly proliferation of command line tools within dripline. It made sense at the time, but looking now...
Why is the sensor logger a special program (for inserting values into the SC database) while the run_table interface is just another service?
Why is the pid loop, which listens for some sub-set of alert messages and then takes an action a dedicated executable and not just a special case of repeater?
Why is there stuff about log Handlers and arg parsers in "core" which is supposed to be about AMQP and general instrument behaviors?
Solutions:
Use subcommands
There should be one dripline command with a reasonable number of subcommands (a la git commit and git log etc...) which covers the things one may want to do. A 'cli_util' directory or similar, parallel to core and instruments, should contain the *.py files which are essentially the existing programs as well as the untility files currently in core or elsewhere. To whatever extent they are not already, their behavior should be encapsulated in a class or function and a parser object made available either for external import or returnable from some exported get_parser() function. The one executable, would then add subcommands to its own master parser for each of them (this provides a good handle for activating/deactivating features for which dependencies are or are not met)....
Make the config file parser more generic
Many of the tools (sensor logger, pid_loop, etc. are almost always evoked with a bunch of flags which could just as well be specified in a config file). This would be nicer since it can be version controlled in the software_config directory and doesn't depend on bash_history not being lost. This involves updating the behavior of the config file parser.
Extra features that would be nice
a dependencies_met() function that tries the required imports for a particular subcommand and returns a bool indicating if requirements are met. The implementation of dripline (the exe) could then test on this before adding subcommands to the arg_parser.
the help for dripline should, ideally, list all of the subcommands and mark as "unmet dependencies" those which are not available. That way a user can use the help to know about features that exist but are not currently active, and why.... If I were cleaver, I'd figure out how to do this using the actual plug-in system for setup.py, since that's probably what it is for.
laroque
commented
8 years ago
There has been a silly proliferation of command line tools within dripline. It made sense at the time, but looking now...
Solutions:
Use subcommands
There should be one
driplinecommand with a reasonable number of subcommands (a lagit commitandgit logetc...) which covers the things one may want to do. A 'cli_util' directory or similar, parallel to core and instruments, should contain the *.py files which are essentially the existing programs as well as the untility files currently in core or elsewhere. To whatever extent they are not already, their behavior should be encapsulated in a class or function and a parser object made available either for external import or returnable from some exported get_parser() function. The one executable, would then add subcommands to its own master parser for each of them (this provides a good handle for activating/deactivating features for which dependencies are or are not met)....Make the config file parser more generic
Many of the tools (sensor logger, pid_loop, etc. are almost always evoked with a bunch of flags which could just as well be specified in a config file). This would be nicer since it can be version controlled in the software_config directory and doesn't depend on bash_history not being lost. This involves updating the behavior of the config file parser.
Extra features that would be nice
References
See https://docs.python.org/2/library/argparse.html#action section 15.4.5.1