In Django, how do you run a management command from Python code with call_command(), and how does that differ from the command line?
answer
- django.core.management's calling function
- keyword options skip the parser
- dest names, not flag spellings
- checks off unless asked
- exceptions propagate, output redirects
basics
~10 scall_command("expire_coupons", dry_run=True, stdout=buf) runs a command in-process. Keyword options bypass argparse and map to dest names, system checks are skipped by default, and CommandError propagates as an exception instead of exiting.
solid answer
~40 s`django.core.management.call_command(name, *args, **options)` loads the command by name (or takes a command instance) and runs it in the current process, returning whatever `handle()` returns. String arguments go through the command's `argparse` parser just like the command line, but **keyword options skip the parser**: you pass real Python types (`verbosity=0`, not `"0"`) under the option's `dest`, or its long flag name with dashes turned into underscores; unknown keywords raise `TypeError`. Unlike the command line, `call_command()` sets `skip_checks=True` unless you pass it, and a `CommandError` is not printed and turned into an exit status — it propagates for you to catch. Pass `stdout=` and `stderr=` (a `StringIO`) to capture output, which is how commands are tested.
code
python · 24 linesfrom datetime import timedelta
from io import StringIO
from django.core.management import CommandError, call_command
from django.test import TestCase
from django.utils import timezone
from shop.models import Coupon
class ExpireCouponsCommandTests(TestCase):
def test_expires_past_coupons(self):
Coupon.objects.create(
code="SPRING", is_active=True,
expires_at=timezone.now() - timedelta(days=1),
)
out = StringIO()
call_command("expire_coupons", stdout=out)
self.assertIn("Expired 1 coupon(s).", out.getvalue())
self.assertFalse(Coupon.objects.get(code="SPRING").is_active)
def test_rejects_negative_grace(self):
with self.assertRaises(CommandError):
call_command("expire_coupons", grace_hours=-1)go deeper
Recall that call_command("name", ...) runs a command from Python and that stdout=StringIO() captures its output in a test.
Explain that keyword options bypass argparse and use dest names, that checks are skipped by default, and that CommandError propagates instead of exiting.
Show the store_false trap, why commands must write through self.stdout to be testable, and when a shared service function beats calling a command from application code.
Set the convention that commands are thin wrappers over tested services, so the same logic runs from the CLI, a scheduler and the application without call_command() in request paths.
## What call_command() is `call_command()` in `django.core.management` is the supported way to run a **management command from Python**: in a test, in a data migration's helper, in another command, or in a script that already has Django configured. The docs are explicit that you should not call a command's `execute()` or `handle()` directly; `call_command()` builds the parser, applies defaults and runs the command through the same `execute()` path the command line uses. ```python from django.core.management import call_command call_command("expire_coupons", "--grace-hours=2") # parsed like the CLI call_command("expire_coupons", grace_hours=2) # keyword: real int, no parsing call_command("expire_coupons", dry_run=True, verbosity=0) ``` The first argument is a command **name** (preferred) or a **command instance**, useful when a test wants to inspect the object afterwards. The return value is whatever `handle()` returned. ## How arguments are passed There are two routes, and they behave differently: - **Positional `*args`** are converted to strings and handed to the command's `argparse` parser, so `"--grace-hours=2"` behaves exactly as on the command line, including type conversion and validation. - **Keyword `**options`** are **not parsed**. They are merged over the parser's defaults as-is, so you must pass the right Python type: `verbosity=0`, not `verbosity="0"`. Keyword names are resolved in two ways: the option's **`dest`** (`use_natural_foreign_keys=True` for `dumpdata`), or its long flag without leading dashes and with inner dashes as underscores (`natural_foreign=True`). Both land on the same `dest`. Unknown keywords raise `TypeError` listing the valid ones. The subtle trap is flags declared with `action="store_false"`. `createsuperuser` declares `--noinput`/`--no-input` with `dest="interactive"`. On the command line the flag *stores False*. As a keyword, `no_input=True` simply sets `interactive=True`, because the value is assigned to the dest without running the action. The correct call is `call_command("createsuperuser", interactive=False, ...)`. ## What differs from the command line | Behaviour | `manage.py expire_coupons` | `call_command("expire_coupons")` | |---|---|---| | Argument parsing | All arguments through `argparse` | Only positional strings; keywords bypass it | | System checks | Run per `requires_system_checks` | Skipped (`skip_checks=True`) unless you pass `skip_checks=False` | | `CommandError` | Printed to stderr, `sys.exit(returncode)` | Raised to the caller | | Bad arguments | argparse prints usage and exits | `CommandError` raised (`Error: ...`) | | Output | Process stdout and stderr | Same, or any file object passed as `stdout=`/`stderr=` | | Database connections | Closed when the command finishes | Left to the calling process | ## Testing a command Testing is the main reason interviewers ask about `call_command()`. The pattern is: 1. Arrange data with the ORM. 2. Call the command with `stdout=StringIO()` (and `stderr=` if it writes there). 3. Assert on the captured text **and** on the database state. 4. Assert failures with `assertRaises(CommandError)`, which only works because `call_command()` propagates the exception. This is why commands should write through `self.stdout` rather than `print()`: a `print()` call bypasses the buffer and the output cannot be asserted on without patching `sys.stdout`. ## Common mistakes - **Passing strings as keyword values**: `call_command("expire_coupons", grace_hours="2")` hands the string `"2"` to `handle()`, because keywords are not converted by `type=int`. Pass `2`, or pass `"--grace-hours=2"` positionally. - **Assuming checks ran**: a command that depends on a system check to catch misconfiguration will not get that protection from `call_command()` unless `skip_checks=False` is passed. - **Catching `SystemExit`**: `call_command()` does not exit on `CommandError`, so wrapping it in `except SystemExit` catches nothing useful. - **Forgetting `stderr=`**: a command that reports problems through `self.stderr` needs its own buffer in a test, or the output leaks to the console. ## When to reach for it - Tests for your own commands. - Composing commands, for example a setup command that calls `migrate` and then `loaddata`. - Admin tooling that must run the same logic as a command without spawning a subprocess. Running `call_command()` inside a web request is almost always a smell: the work belongs in a function or service that both the command and the view call, so the command stays a thin command-line wrapper.
- Why does call_command("createsuperuser", no_input=True) still prompt for input?Keyword options bypass `argparse`, so the `store_false` action of `--no-input` never runs. `no_input` is mapped to the option's dest, `interactive`, and the value `True` is assigned to it, which keeps prompting on. Pass the dest with the intended value: `interactive=False`, along with the required username and email options.
- Your command's tests pass with call_command() but it fails on the server with a system-check error; how can that happen?`call_command()` skips system checks unless you pass `skip_checks=False`, while `manage.py` runs the checks selected by `requires_system_checks` before `handle()`. A check error that tests never trigger therefore surfaces only on the command line. Pass `skip_checks=False` in one test, or run `manage.py check` in CI, to catch it earlier.
saying these in an interview costs you the question
- call_command() parses keyword options through argparse like the CLI
- call_command() exits the process with status 1 on CommandError
- Keyword names must match the flag with its leading dashes
- call_command() runs every system check before the command
- Calling Command().handle() directly is the supported way to run commands