That's not really the issue with argparse and subcommands. argparse with subcommands generally requires specifying all of the options for all of the subcommand

That's not really the issue with argparse and subcommands. argparse with subcommands generally requires specifying all of the options for all of the subcommands, even if you only want one subcommand. These in turn may require importing subcommand-specific modules, to handle things like the right 'type' handler in an an add_argument() parameter. This callback function might, depending on the input value, select one from a dozen different additional packages. It's possible to avoid this, by deferring argument->type processing until later, and having a single large module containing all of the help strings and epilogs, though this will separate your argparse code from your subcommand code, and in general make things more complicated. I did this for a while. Alternatively, you can create your own subcommand dispatch system using an nargs="?" to get the subcommand and an nargs=argparse.REMAINDER to capture the rest of the flags, to pass to a new ArgumentParser, and develop a top-level --help replacements. I tried this too. I've since decided to use click, which does a better job at compartmentalizing at least this level of subcommand imports.