Is it possible to create subparsers in a django management command?

Question

Title really says it all, but I currently have this, but it doesn't work:

class Command(BaseCommand):
    help = ("Functions related to downloading, parsing, and indexing the  "
            "content")

    def add_arguments(self, parser):
        subparsers = parser.add_subparsers()

        download_parser = subparsers.add_parser(
            'download',
            help='Using a local CSV, download the XML data for content. '
                 'Output is sent to the log.'
        )
        download_parser.add_argument(
            '--start_line',
            type=int,
            default=0,
            help='The line in the file where you wish to start processing.'
        )

        # Add an argparse parser for parsing the content. Yes, this is
        # a bit confusing.
        content_parser_parser = subparsers.add_parser(
            'parse',
            help="Look at the file system and parse everything you see so that "
                 "we have content in the databse."
        )
        content_parser_parser.add_argument(
            '--start_item',
            type=int,
            default=0,
            help="Assuming the content is sorted by file name, this item is "
                 "the one to start on."
        )

My specific idea is to create one command that has subcommands for downloading XML content or for parsing it into the database.

Answer 1

Django 2.1 and above

In Django 2.1 and above, adding a subcommand is trivial:

from django.core.management.base import BaseCommand

class Command(BaseCommand):

    def add_arguments(self, parser):
        subparsers = parser.add_subparsers(title="subcommands",
                                           dest="subcommand",
                                           required=True)

Then you use subparser the same way you'd do if you were writing a non-Django application that uses argparse. For instance, if you want a subcommand named foo that may take the --bar argument:

foo = subparsers.add_parser("foo")
foo.set_defaults(subcommand=fooVal)
foo.add_argument("--bar")

The value fooVal is whatever you decide the subcommand option should be set to when the user specifies the foo subcommand. I often set it to a callable.

Older versions of Django

It is possible but it requires a bit of work:

from django.core.management.base import BaseCommand, CommandParser

class Command(BaseCommand):

    [...]

    def add_arguments(self, parser):
        cmd = self

        class SubParser(CommandParser):

            def __init__(self, **kwargs):
                super(SubParser, self).__init__(cmd, **kwargs)

        subparsers = parser.add_subparsers(title="subcommands",
                                           dest="subcommand",
                                           required=True,
                                           parser_class=SubParser)

When you call add_subparsers by default argparse creates a new parser that is of the same class as the parser on which you called add_subparser. It so happens that the parser you get in parser is a CommandParser instance (defined in django.core.management.base). The CommandParser class requires a cmd argument before the **kwargs (whereas the default parser class provided by argparse only takes **kwargs):

def __init__(self, cmd, **kwargs):

So when you try to add the subparser, it fails because the constructor is called only with **kwargs and the cmd argument is missing.

The code above fixes the issue by passing in parser_class argument a class that adds the missing parameter.

Things to consider:

1. In the code above, I create a new class because the name parser_class suggests that what should be passed there is a real class. However, this also works:

   def add_arguments(self, parser):
       cmd = self
       subparsers = parser.add_subparsers(
           title="subcommands",
           dest="subcommand",
           required=True,
           parser_class=lambda **kw: CommandParser(cmd, **kw))
   

   Right now I've not run into any issues but it is possible that a future change to argparse could make using a lambda rather than a real class fail. Since the argument is called parser_class and not something like parser_maker or parser_manufacture I would consider such a change to be fair game.

2. Couldn't we just pass one of the stock argparse classes rather than pass a custom class in parser_class? There would be no immediate problem, but there would be unintended consequences. The comments in CommandParser show that the behavior of argparse's stick parser is undesirable for Django commands. In particular, the docstring for the class states:

   """
   Customized ArgumentParser class to improve some error messages and prevent
   SystemExit in several occasions, as SystemExit is unacceptable when a
   command is called programmatically.
   """
   

   This is a problem that Jerzyk's answer suffers from. The solution here avoids that problem by deriving from CommandParser and thus providing the correct behavior needed by Django.