1. client application ex: heron (for heron-cli) or heron-tracker
2. sub command : ex. activate , kill
3. cluster/env/role : devcluster/ads/PROD
HeronRC supports an implicit hierarchy so that argument collisions can be handled. Heron RC also discourages the use of positional arguments , and only recommends the use of key value pairs.
##Hierarchy: *client |___ *subcommand |_______*cluster/env/role
Heron RC supports wild card subsititutions in the above hierarchy. Please note that the supported wild card is just ‘*’. we dont support regex (not yet:)
##Features :
supports the following patterns
handles removal of comments and invalid args (see patterns #f and #g)
Precedence -
support for positional arguments
##Assumptions: command and role/cluster/env are positional arguments and are in #1 and #2 to all heron RC supported applications the application has a designated identifier : for example : heron-cli has heron
To run/Test : (make sure the init.py files are in all places and you have a sample heron rc file in the directory - ex: heron/cli/tests/python/)
unit2 -v heron.cli.tests.python.heronparser_unittest or python -m heron.cli.tests.python.heronparser_unittest or python -m unittest2 heron.cli.tests.python.heronparser_unittest
test_parser_commandline (__main__.HeronParserTest) ... ok test_parser_norcfile (__main__.HeronParserTest) ... ok test_parser_rolecmdspecific (__main__.HeronParserTest) ... ok ---------------------------------------------------------------------- Ran 3 tests in 0.006s OK
to build:
./docker/build-docker.sh ubuntu14.04 0.14.1 ../heron-release