Use argparse subparsers for subcommands

[csomh]

Makes argument parsing more resilient, by handling
subcommands with argparse provided and recommended subparsers,
instead of the current custom manipulation of argv.

Removes the need to manually update and format the top-level
help message: this is going to be composed from the help strings
of the subcommands by argparse.

Fixes the issue of subcommand's usage string not displaying the
subcommand.

Removes the need to explicitly check for incorrect subcommands.

Enables extending the CLI with top-level optional arguments, without the
need of adjusting argv parsing.

[openshift-ci-robot]

Hi @csomh. Thanks for your PR.

I'm waiting for a operator-framework or openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[kevinrizza]

What is the advantage of using subcommand versus the current implementation?

Also, #77 should be solved by a separate pr. Please do not co-mingle multiple changes in a single pull request.

[csomh]

Subparsers are the argparse provided way to handle subcommands. Switching to this was easier than figuring out the bug in the custom implementation, which was causing #77 or led to an incorrect usage text to be displayed for subcommands.

Sorry, the commit message didn't clarify this. Updated it, together with the initial PR comment.

[kevinrizza]

How do you know that there was a bug at all? It seems like the command has description output, and I'm not sure that your change fixed any bug at all. It seems more likely to me that the issue in question was describing a perceived lack of documentation about what the flag outputs (aside from the very basic description of the flag).

That could be a separate discussion, but I don't think this PR fixes the issue.

And, again, I still don't see what using subcommands contributes here. Is there some design limitation to the current implementation (aside from not using some specific sub library)? What does moving to using subcommand actually give us that we don't have already? If there is a technical argument to be made for them, I am certainly interested in hearing it.

[csomh]

Oh, ok, I see now. You're right.

[MartinBasti]

This PR is still valid (but must be updated), There were already several issues caused by not using subparsers.

• Add flatten command #85
• CLI: Add --verbose mode option #89
• Refactor the way subcommands are parsed in cli.py #88

[kevinrizza]

Please update the commit message to stop referencing #77 since this does not resolve the issue, and please give a more detailed description of what problems this implementation resolves.

[csomh]

Updated.

[kevinrizza]

/lgtm

[MartinBasti]

works for me