CommandParser
=============

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