CommandParser 0.3

change objects to OptionParser instances via reflection

change objects to OptionParser instances via reflection

Overview

It is a common pattern for command line interfaces to use subcomands (e.g.):

hg commit -m ‘foo bar’ git push origin master

CommandParser does this via introspection of a given class. When invoked with a class, CommandParser uses the inspect module to pull out the mandatory and optional arguments for each of the class’s methods, which are translated to subcommands, and make a OptionParser instance from them. %prog help will then display all of the subcommands and %prog help <subcommand> will give you help on the <subcommand> chosen. Methods beginning with an underscore (_) are passed over. This gives an easy way to translate an API class into a command line program:

class Foo(object):
  """silly class that does nothing"""
  def __init__(self): pass
  def foo(self, value):
    print "The value is %s" % value
  def bar(self, fleem, verbose=False):
    """
    The good ole `bar` command
    - fleem: you know, that thing fleem
    - verbose: whether to print out more things or not
    """
    if verbose:
      print "You gave fleem=%s" % fleem
    return fleem * 2

import commandparser
parser = commandparser.CommandParser(Foo)
parser.invoke()

(From http://k0s.org/hg/CommandParser/file/tip/tests/simpleexample.py )

Example invocation:

(paint)│./simpleexample.py help
Usage: simpleexample.py [options] command [command-options]

silly class that does nothing

Options:
  -h, --help  show this help message and exit

Commands:
  bar   The good ole `bar` command
  foo
  help  print help for a given command
(paint)│./simpleexample.py foo
Usage: simpleexample.py foo <value>

simpleexample.py: error: Not enough arguments given
(paint)│./simpleexample.py foo 4
The value is 4
(paint)│./simpleexample.py bar blah
blahblah

For optional arguments, the type of the default value will be inspected from the function signature. Currently, mandatory arguments are all strings, though this is clearly a shortcoming.

The class docstring is used for %prog --help (and %prog help, same thing). The method docstrings (including those of __init__ for global options) are used for subcommand help. If the arguments are listed in the docstring in the form given above (- <argument> : <something about the argument) then these are used to provide help on the individual options. Otherwise, these are left blank.

For straight-forward cases, it may be enough to pass your class directly to the CommandParser constructor. For more complex cases, it is an advisable pattern to create a new class (either via subclassing or e.g. rolling from scratch, as applicable) that is more amenable to CommandParser rather than modifying an (e.g.) API class to fit what CommandParser expects. This allows the use of an object-oriented interface for subcommands without sacrificing your API class, and if you can subclass then there’s really not much extra code to write.

See http://k0s.org/hg/CommandParser/file/tip/tests for tests and examples.

Reference

• https://pypi.python.org/pypi/clime/ is a similar effort

---

Jeff Hammel

http://k0s.org/hg/CommandParser