tambo 0.0.4

Command Line Class

The command line class is what tambo would look forward when dispatching to subcommands. They need to follow a couple of constraints but will still allow to handle the command line arguments in whatever way you want with whatever library you want.

The most simple class you would need to have a valid dispatch call would look like this (following the example of the verbose flag from above):

class MySubCommand(object):

    def __init__(self, argv):
        self.argv = argv

    def parse_args(self):
        if '--verbose' in self.argv:
            my_program.verbose()

In tambo internals, the above class will get called when it matches the mapping defined in your root dictionary, and will receive the argv argument which is nothing else than the list of arguments (same as what you would expect from sys.argv received on the command line. If we are following the examples from above, the call would’ve been like this on the CLI:

my_cli subcommand --verbose

Using tambo parsed args

Although you can use whatever argument parser you want, tambo also comes with its own little engine that maps arguments in the command line to values, that represents the flags and arguments that you expect:

from tambo import Transport

class MySubCommand(object):

    def __init__(self, argv):
        self.argv = argv
        self.parser = Transport(self.argv)

    def parse_args(self):
        if self.parser.has('--verbose'):
            my_program.verbose()

In the above case --verbose wasn’t expecting a value assigned so later we just verified it existed by calling has('--verbose').

The Transport object allows you to define all the flags and options you need as a tuple or a list so that they can be taken into account when mapping the values. If you want to define aliases, you can do so by grouping them in a list within the main list passed in to Transport:

>>> from tambo import Transport
>>> options = [['-i', '--import'], '--verbose']
>>> parse = Transport(options)
>>> sys_argv = ['/bin/myapp', '-i', 'somevalue']
>>> parse.parse_args(sys_argv)
>>> parse.get('-i')
'somevalue'
>>> parse.get('--import')
'somevalue'

So aliases work by grouping them together in a list, but what happens on boolean flags? You can check them by calling the has method:

>>> sys_argv = ['/bin/myapp', '--verbose']
>>> parse.parse_args(sys_argv)
>>> parse.has('-i')
False
>>> parse.has('--verbose')
True

If you need to check for boolean flags in batch, you can pass in a list:

>>> sys_argv = ['/bin/myapp', '--verbose']
>>> parse.parse_args(sys_argv)
>>> parse.has('-i')
False
>>> parse.has(['-v', '--verbose'])
True

Help generation

A common problem for subcommands and command line tools that have these is generating help in a semi-automated way. tambo has a way to do this for subcommands that are mapped by calling the help property if there is one and would in turn outpout that information when called:

class MySubcommandClass(object):

    help = 'A sub-command that does some stuff'

And then in the handler for your arguments it will automaticall check for the presence of the help attribute to display it if needed:

# parser is an instance of the Transport class from ``tambo``
parser.parse_args()

Which would make sure that when help is set on the command line it would output something like this:

my_cli_tool version 0.0.1

SubCommands:

subcommand          A sub-command that does some stuff

This is again, entirely optional, as you can avoid making those calls to catch help by telling the Transport class to avoid checking for it:

parser = Transport(sys.argv, check_help=False)

If for some reason you wanted to force printing the help menu, for example when no options have been matched, you can also do that with print_help()

parser = Transport(sys.argv, check_help=False)

if parser.has('--verbose'):
    my_program.verbose()
else:
    parser.print_help()