Unandled exception if ArgparseController is missing default function

Using ArgparseController without a default command results in an unhandled exception.

Code:

from cement.core.foundation import CementApp
from cement.ext.ext_argparse import ArgparseController, expose


class MyBaseController(ArgparseController):
    @expose(help='<Subcommand description>')
    def subcommand(self):
        self.app.log.info("subcommand successful")


class MyApp(CementApp):
    class Meta:
        label = 'demo'
        handlers = [MyBaseController]


with MyApp() as app:
    app.run()

The help output looks as expected:

> python3 demo4.py --help
usage: demo [-h] [--debug] [--quiet] {subcommand} ...

optional arguments:
  -h, --help    show this help message and exit
  --debug       toggle debug output
  --quiet       suppress all output

sub-commands:
  {subcommand}
    subcommand  <Subcommand description>

But running with no command raises an exception:

> python3 demo4.py
Traceback (most recent call last):
  File "demo4.py", line 18, in <module>
    app.run()
  File "C:\Python34\lib\site-packages\cement\core\foundation.py", line 882, in run
    return_val = self.controller._dispatch()
  File "C:\Python34\lib\site-packages\cement\ext\ext_argparse.py", line 927, in _dispatch
    (contr.__class__.__name__, func_name))      # pragma: nocover
cement.core.exc.FrameworkError: Controller function does not exist MyBaseController.default()

It seems that, if there is no default function, the best thing would be to output a parse error, as if the user had typed in an invalid function.

Otherwise, I take it that the default function is required by cement, in which case a doc update might be appropriate: http://builtoncement.com/2.10/api/ext/ext_argparse.html#cement-ext-ext-argparse

Thoughts?

(Obviously a good workaround is to create a default command and print the help text.)

[leefowlercu]

@derks I can confirm that @expose(hide=True) does hide the commands from the sub-commands: list but still shows them both on the usage line:

usage: conduit [-h] [--debug] [--quiet] {default,test-command} ...

and on the sub-commands shortlist:

sub-commands:
  {default,test-command}

I’d argue that for every other command other than default this is probably the intended behavior. But, since the default command is enforced by the framework, the default command showing those places is confusing clutter. Users will almost always invoke a command via <command> as opposed to <command> default.

Having it show in those lists is both confusing from a user-perspective and aesthetically displeasing from a developer perspective.

Edit: My intended use-case for cement is to produce a CLI application with two different modes of operation, and as such, I don’t want a default implementation for the base command (other than printing usage information). The usage scenario would be:

<application> -application_options <mode_1> -mode_1_options and <application> -application_options <mode_2> -mode_2_options.

Enforcing an implementation of the default command on the base controller makes this extremely difficult, and again, clutters the usage info with the irrelevant default command

[derks]

@jtpereyda as an aside, you can use @expose(hide=True) so that the default (or other functions) don’t show in --help.