Comment 4 for bug 1290018

Rahul,

cliff does support subcommands, but not quite the way you seem to want to use them.

The command line structure I think you want is:

  libcloud --app-option app-val service1 --service1-option resource1 --shared-option val1 action1 --action1-option
  libcloud --app-option app-val service1 --service1-option resource1 --shared-option val1 action2 --action2-option

Having the parts of the command and the options mixed feels a little harder for users to understand, but obviously that's subjective.

First, in case it's not clear from the docs and example, a "command" can include more than one word. In the openstack client we have commands like "subnet list" and "subnet show". Those are listed as individual commands, but tab-completion makes them appear to the user as though they are subcommands (we went with "noun verb" to facilitate discovery through tab completion).

Cliff also supports having commands share options, because each command implementation is a class, and you can inherit the option definitions from a parent class.

So if you have a command "service1 resource1 action1" and another command "service1 resource1 action2" those could inherit from a Service1Resource1Base which defines the method to configure the common options. The Service1Resource1Action1 and Servide1Resource1Action2 classes could then add their own custom options. If there are application options for things like login credentials or configuration files, those can be defined by the application base class and consumed by the application, before any command class is loaded.

Using that structure, some libcloud command might look like:

  libcloud --app-option app-val service1 resource1 action1 --service1-option --shared-option val1 --action1-option
  libcloud --app-option app-val service1 resource1 action2 --service1-option --shared-option val1 --action2-option

with "service1 resource1 action1" mapping to a single class in your entry point metadata. The show and list command base classes are examples of this, since each introduces the appropriate formatter options but relies on the subclass to provide output data.

The openstack client uses application options (http://git.openstack.org/cgit/openstack/python-openstackclient/tree/openstackclient/shell.py#n135) but I don't see an example of us building an equivalent to Service1Resource1Base anywhere.