~tribaal/charms/precise/storage/refactor-mount-volume

« back to all changes in this revision

Viewing changes to hooks/charmhelpers/cli/README.rst

  • Committer: David Britton
  • Date: 2014-02-05 20:46:42 UTC
  • mfrom: (26.1.89 storage)
  • Revision ID: dpb@canonical.com-20140205204642-qfwv0x6314bulcx7
merging chad's python/nfs additions

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
==========
 
2
Commandant
 
3
==========
 
4
 
 
5
-----------------------------------------------------
 
6
Automatic command-line interfaces to Python functions
 
7
-----------------------------------------------------
 
8
 
 
9
One of the benefits of ``libvirt`` is the uniformity of the interface: the C  API (as well as the bindings in other languages) is a set of functions that accept parameters that are nearly identical to the command-line arguments.  If you run ``virsh``, you get an interactive command prompt that supports all of the same commands that your shell scripts use as ``virsh`` subcommands.
 
10
 
 
11
Command execution and stdio manipulation is the greatest common factor across all development systems in the POSIX environment.  By exposing your functions as commands that manipulate streams of text, you can make life easier for all the Ruby and Erlang and Go programmers in your life.
 
12
 
 
13
Goals
 
14
=====
 
15
 
 
16
* Single decorator to expose a function as a command.
 
17
  * now two decorators - one "automatic" and one that allows authors to manipulate the arguments for fine-grained control.(MW)
 
18
* Automatic analysis of function signature through ``inspect.getargspec()``
 
19
* Command argument parser built automatically with ``argparse``
 
20
* Interactive interpreter loop object made with ``Cmd``
 
21
* Options to output structured return value data via ``pprint``, ``yaml`` or ``json`` dumps.
 
22
 
 
23
Other Important Features that need writing
 
24
------------------------------------------
 
25
 
 
26
* Help and Usage documentation can be automatically generated, but it will be important to let users override this behaviour
 
27
* The decorator should allow specifying further parameters to the parser's add_argument() calls, to specify types or to make arguments behave as boolean flags, etc.
 
28
    - Filename arguments are important, as good practice is for functions to accept file objects as parameters.
 
29
    - choices arguments help to limit bad input before the function is called
 
30
* Some automatic behaviour could make for better defaults, once the user can override them.
 
31
    - We could automatically detect arguments that default to False or True, and automatically support --no-foo for foo=True.
 
32
    - We could automatically support hyphens as alternates for underscores
 
33
    - Arguments defaulting to sequence types could support the ``append`` action.
 
34
 
 
35
 
 
36
-----------------------------------------------------
 
37
Implementing subcommands
 
38
-----------------------------------------------------
 
39
 
 
40
(WIP)
 
41
 
 
42
So as to avoid dependencies on the cli module, subcommands should be defined separately from their implementations. The recommmendation would be to place definitions into separate modules near the implementations which they expose.
 
43
 
 
44
Some examples::
 
45
 
 
46
    from charmhelpers.cli import CommandLine
 
47
    from charmhelpers.payload import execd
 
48
    from charmhelpers.foo import bar
 
49
 
 
50
    cli = CommandLine()
 
51
 
 
52
    cli.subcommand(execd.execd_run)
 
53
 
 
54
    @cli.subcommand_builder("bar", help="Bar baz qux")
 
55
    def barcmd_builder(subparser):
 
56
        subparser.add_argument('argument1', help="yackety")
 
57
        return bar