Register subparsers recursively

[victorlin]

Description of proposed changes

Motivated by the desire to set a non-default formatter for all parsers including the top-level parser and subparsers.

Related issue(s)

• Prepping for Improve help text of CLI command descriptions #313 (comment)

Checklist

• Add back create_shared_parser to fix augur curate
• Automated checks pass
• Check if you need to add a changelog message
• Check if you need to add tests
• Check if you need to update docs

[victorlin]

This breaks augur curate subcommands

$ cat records.ndjson | augur curate passthru
Traceback (most recent call last):
  File "…/augur/__init__.py", line 72, in run
    return args.__command__.run(args)
TypeError: run() missing 1 required positional argument: 'records'

because each subcommand's run function is expected to be called through augur curate's own run function, but it is now called directly at the top level.

Maybe recursively registering subcommands is not the right thing to do in this codebase.

[joverlee521]

I remember having to work around the top level run when initially adding the augur curate subcommand.

augur/augur/curate/__init__.py

Lines 117 to 120 in 129fd7e

	# Using a subcommand attribute so subcommands are not directly
	# run by top level Augur. Process I/O in `curate`` so individual
	# subcommands do not have to worry about it.
	add_command_subparsers(subparsers, SUBCOMMANDS, SUBCOMMAND_ATTRIBUTE)

Would it be weird to keep augur curate as a special case?

[tsibley]

Two options:

1. Further adapt how augur curate commands share functionality so calling their run() from the top-level works. This could be done relatively straightforwardly.
2. Don't recursively register subcommands; leave the pattern of commands with subcommands invoking register_commands(…) themselves.

I don't think either gets the way of the functional improvements we want to make? So it's a matter of preference.

[victorlin]

Thanks for the input – I'll try option 1 above to align with Nextstrain CLI code.