initialize_app is not called when running --help

[Alessandro Molina]

If subclasses added sub-commands during App.initialize_app hook, they are correctly available when called but are not listed when running "--help".

This is because parser.parse_known_args calls the HelpAction skipping the run method in total.

In case sub-commands might depend on some parser options (for example be available only with --expert option) they have to be registered during initialize_app when self.options is available. This causes that those commands are never listed in the help.

Would it make sense to avoid using "action=HelpAction" and actually handle the help in App.run so that it is part of the standard application flow?

[Doug Hellmann (doug-hellmann)]

Options added by overriding build_option_parser() will appear in the help output. It looks like that's not in the tutorial, so we need to update the docs.

I'm not sure I follow the use case for an expert mode flag. That turns on options that aren't otherwise available? Why?

[Alessandro Molina (alessandro-molina)]

The issue is with subcommands, if you register subcommands in the command_manager based on an option, they won't be listed in the help.

My --expert example was to clearly expose the issue.
Suppose you have a --expert example that enables/disables some subcommands, they will never be listed inside the help (even when --expert is specified) because you never get to initialize_app where the subcommands are added. And you cannot register the subcommands before initialize_app because the option have not been parsed yet and you don't know if --export is true or false yet.

Generally speaking, the issue is that everything you do in initialize_app has not happened yet when the HelpAction is executed (and will actually never happen as the HelpAction does exit(0))

[Dean Troyer (dtroyer)]

This sounds similar to what I did in OpenStackClient to delay HelpAction until after the API-versioned commands were loaded. In that case I removed the -h/--help options from the parser and replaced it with one that just sets a flag (https://github.com/openstack/python-openstackclient/blob/master/openstackclient/shell.py#L97) then call HelpAction from inside initialize_app() (https://github.com/openstack/python-openstackclient/blob/master/openstackclient/shell.py#L97).

It sounds like it may be worthwhile to look at a way to modify help behaviour to at least let initialize_app() get called.

[Doug Hellmann (doug-hellmann)]

Isn't initialize_app is supposed to be able to do things like create database connections or get keystone tokens? To do that it needs the arguments to have been parsed. We might need a separate hook for this.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/158343

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/158343
Committed: https://git.openstack.org/cgit/openstack/cliff/commit/?id=9d37798bc123910952a53630ba22f70c1997529d
Submitter: Jenkins
Branch: master

commit 9d37798bc123910952a53630ba22f70c1997529d
Author: Cedric Brandily <email address hidden>
Date: Mon Feb 23 16:58:33 2015 +0100

    Allow to call initialize_app when running --help

    Currently initialize_app is not called when running --help. Some
    applications (like openstackclient) define its sub-commands in
    initialize_app. So sub-commands are hidden when running '--help' except
    if applications hack cliff to defer help print (openstackclient case).

    This change defines a new option to allow deferring help print after
    initialize_app. Openstackclient will be updated in a follow-up change
    in order to remove previous hack.

    Change-Id: I0c6fb93d5713654b180b4488e85118c1818fdfb0
    Closes-Bug: #1316622