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:
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.
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.
parseralready, or whatdjangodoes it with it later, I can't say. Off hand your subparser definitions look fine. But as you may see from other SO questions, making subparsers work with other arguments, positional and/or optionals, can be tricky. Just as a diagnostic, addprint parser._actionsat the start of your function. – Circularize