1DJANGO-ADMIN(1) Django DJANGO-ADMIN(1)
2
6 django-admin - Utility script for the Django Web framework
7 django-admin is Django's command-line utility for administrative tasks.
9 This document outlines all it can do.
10 In addition, manage.py is automatically created in each Django project.
12 manage.py does the same thing as django-admin but takes care of a few
13 things for you:
14 · It puts your project's package on sys.path.
16 · It sets the DJANGO_SETTINGS_MODULE environment variable so that it
18 points to your project's settings.py file.
19 The django-admin script should be on your system path if you installed
21 Django via its setup.py utility. If it's not on your path, you can find
22 it in site-packages/django/bin within your Python installation. Con‐
23 sider symlinking it from some place on your path, such as
24 /usr/local/bin.
25 For Windows users, who do not have symlinking functionality available,
27 you can copy django-admin.exe to a location on your existing path or
28 edit the PATH settings (under Settings - Control Panel - System -
29 Advanced - Environment...) to point to its installed location.
30 Generally, when working on a single Django project, it's easier to use
32 manage.py than django-admin. If you need to switch between multiple
33 Django settings files, use django-admin with DJANGO_SETTINGS_MODULE or
34 the --settings command line option.
35 The command-line examples throughout this document use django-admin to
37 be consistent, but any example can use manage.py or python -m django
38 just as well.
39
41 $ django-admin <command> [options]
42 $ manage.py <command> [options]
43 $ python -m django <command> [options]
44 command should be one of the commands listed in this document.
46 options, which is optional, should be zero or more of the options
47 available for the given command.
48 Getting runtime help
50 django-admin help
51 Run django-admin help to display usage information and a list of the
53 commands provided by each application.
54 Run django-admin help --commands to display a list of all available
56 commands.
57 Run django-admin help <command> to display a description of the given
59 command and a list of its available options.
60 App names
62 Many commands take a list of "app names." An "app name" is the basename
63 of the package containing your models. For example, if your
64 INSTALLED_APPS contains the string 'mysite.blog', the app name is blog.
65 Determining the version
67 django-admin version
68 Run django-admin version to display the current Django version.
70 The output follows the schema described in PEP 440:
72 1.4.dev17026
74 1.4a1
75 1.4
76 Displaying debug output
78 Use --verbosity to specify the amount of notification and debug infor‐
79 mation that django-admin prints to the console.
80
82 check
83 django-admin check [app_label [app_label ...]]
84 Uses the system check framework to inspect the entire Django project
86 for common problems.
87 By default, all apps will be checked. You can check a subset of apps by
89 providing a list of app labels as arguments:
90 django-admin check auth admin myapp
92 If you do not specify any app, all apps will be checked.
94 --tag TAGS, -t TAGS
96 The system check framework performs many different types of checks that
98 are categorized with tags. You can use these tags to restrict the
99 checks performed to just those in a particular category. For example,
100 to perform only models and compatibility checks, run:
101 django-admin check --tag models --tag compatibility
103 --list-tags
105 Lists all available tags.
107 --deploy
109 Activates some additional checks that are only relevant in a deployment
111 setting.
112 You can use this option in your local development environment, but
114 since your local development settings module may not have many of your
115 production settings, you will probably want to point the check command
116 at a different settings module, either by setting the DJANGO_SET‐
117 TINGS_MODULE environment variable, or by passing the --settings option:
118 django-admin check --deploy --settings=production_settings
120 Or you could run it directly on a production or staging deployment to
122 verify that the correct settings are in use (omitting --settings). You
123 could even make it part of your integration test suite.
124 --fail-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}
126 Specifies the message level that will cause the command to exit with a
128 non-zero status. Default is ERROR.
129 compilemessages
131 django-admin compilemessages
132 Compiles .po files created by makemessages to .mo files for use with
134 the built-in gettext support. See /topics/i18n/index.
135 --locale LOCALE, -l LOCALE
137 Specifies the locale(s) to process. If not provided, all locales are
139 processed.
140 --exclude EXCLUDE, -x EXCLUDE
142 Specifies the locale(s) to exclude from processing. If not provided, no
144 locales are excluded.
145 --use-fuzzy, -f
147 Includes fuzzy translations into compiled files.
149 Example usage:
151 django-admin compilemessages --locale=pt_BR
153 django-admin compilemessages --locale=pt_BR --locale=fr -f
154 django-admin compilemessages -l pt_BR
155 django-admin compilemessages -l pt_BR -l fr --use-fuzzy
156 django-admin compilemessages --exclude=pt_BR
157 django-admin compilemessages --exclude=pt_BR --exclude=fr
158 django-admin compilemessages -x pt_BR
159 django-admin compilemessages -x pt_BR -x fr
160 createcachetable
162 django-admin createcachetable
163 Creates the cache tables for use with the database cache backend using
165 the information from your settings file. See /topics/cache for more
166 information.
167 --database DATABASE
169 Specifies the database in which the cache table(s) will be created.
171 Defaults to default.
172 --dry-run
174 Prints the SQL that would be run without actually running it, so you
176 can customize it or use the migrations framework.
177 dbshell
179 django-admin dbshell
180 Runs the command-line client for the database engine specified in your
182 ENGINE setting, with the connection parameters specified in your USER,
183 PASSWORD, etc., settings.
184 · For PostgreSQL, this runs the psql command-line client.
186 · For MySQL, this runs the mysql command-line client.
188 · For SQLite, this runs the sqlite3 command-line client.
190 · For Oracle, this runs the sqlplus command-line client.
192 This command assumes the programs are on your PATH so that a simple
194 call to the program name (psql, mysql, sqlite3, sqlplus) will find the
195 program in the right place. There's no way to specify the location of
196 the program manually.
197 --database DATABASE
199 Specifies the database onto which to open a shell. Defaults to default.
201 diffsettings
203 django-admin diffsettings
204 Displays differences between the current settings file and Django's
206 default settings (or another settings file specified by --default).
207 Settings that don't appear in the defaults are followed by "###". For
209 example, the default settings don't define ROOT_URLCONF, so ROOT_URL‐
210 CONF is followed by "###" in the output of diffsettings.
211 --all
213 Displays all settings, even if they have Django's default value. Such
215 settings are prefixed by "###".
216 --default MODULE
218 The settings module to compare the current settings against. Leave
220 empty to compare against Django's default settings.
221 --output {hash,unified}
223 Specifies the output format. Available values are hash and unified.
227 hash is the default mode that displays the output that's described
228 above. unified displays the output similar to diff -u. Default set‐
229 tings are prefixed with a minus sign, followed by the changed setting
230 prefixed with a plus sign.
231 dumpdata
233 django-admin dumpdata [app_label[.ModelName] [app_label[.ModelName]
234 ...]]
235 Outputs to standard output all data in the database associated with the
237 named application(s).
238 If no application name is provided, all installed applications will be
240 dumped.
241 The output of dumpdata can be used as input for loaddata.
243 Note that dumpdata uses the default manager on the model for selecting
245 the records to dump. If you're using a custom manager as the default
246 manager and it filters some of the available records, not all of the
247 objects will be dumped.
248 --all, -a
250 Uses Django's base manager, dumping records which might otherwise be
252 filtered or modified by a custom manager.
253 --format FORMAT
255 Specifies the serialization format of the output. Defaults to JSON.
257 Supported formats are listed in serialization-formats.
258 --indent INDENT
260 Specifies the number of indentation spaces to use in the output.
262 Defaults to None which displays all data on single line.
263 --exclude EXCLUDE, -e EXCLUDE
265 Prevents specific applications or models (specified in the form of
267 app_label.ModelName) from being dumped. If you specify a model name,
268 the output will be restricted to that model, rather than the entire
269 application. You can also mix application names and model names.
270 If you want to exclude multiple applications, pass --exclude more than
272 once:
273 django-admin dumpdata --exclude=auth --exclude=contenttypes
275 --database DATABASE
277 Specifies the database from which data will be dumped. Defaults to
279 default.
280 --natural-foreign
282 Uses the natural_key() model method to serialize any foreign key and
284 many-to-many relationship to objects of the type that defines the
285 method. If you're dumping contrib.auth Permission objects or con‐
286 trib.contenttypes ContentType objects, you should probably use this
287 flag. See the natural keys documentation for more details on this and
288 the next option.
289 --natural-primary
291 Omits the primary key in the serialized data of this object since it
293 can be calculated during deserialization.
294 --pks PRIMARY_KEYS
296 Outputs only the objects specified by a comma separated list of primary
298 keys. This is only available when dumping one model. By default, all
299 the records of the model are output.
300 --output OUTPUT, -o OUTPUT
302 Specifies a file to write the serialized data to. By default, the data
304 goes to standard output.
305 When this option is set and --verbosity is greater than 0 (the
307 default), a progress bar is shown in the terminal.
308 flush
310 django-admin flush
311 Removes all data from the database and re-executes any post-synchro‐
313 nization handlers. The table of which migrations have been applied is
314 not cleared.
315 If you would rather start from an empty database and re-run all migra‐
317 tions, you should drop and recreate the database and then run migrate
318 instead.
319 --noinput, --no-input
321 Suppresses all user prompts.
323 --database DATABASE
325 Specifies the database to flush. Defaults to default.
327 inspectdb
329 django-admin inspectdb [table [table ...]]
330 Introspects the database tables in the database pointed-to by the NAME
332 setting and outputs a Django model module (a models.py file) to stan‐
333 dard output.
334 You may choose what tables or views to inspect by passing their names
336 as arguments. If no arguments are provided, models are created for
337 views only if the --include-views option is used.
338 Use this if you have a legacy database with which you'd like to use
340 Django. The script will inspect the database and create a model for
341 each table within it.
342 As you might expect, the created models will have an attribute for
344 every field in the table. Note that inspectdb has a few special cases
345 in its field-name output:
346 · If inspectdb cannot map a column's type to a model field type, it'll
348 use TextField and will insert the Python comment 'This field type is
349 a guess.' next to the field in the generated model. The recognized
350 fields may depend on apps listed in INSTALLED_APPS. For example,
351 django.contrib.postgres adds recognition for several PostgreSQL-spe‐
352 cific field types.
353 · If the database column name is a Python reserved word (such as
355 'pass', 'class' or 'for'), inspectdb will append '_field' to the
356 attribute name. For example, if a table has a column 'for', the gen‐
357 erated model will have a field 'for_field', with the db_column
358 attribute set to 'for'. inspectdb will insert the Python comment
359 'Field renamed because it was a Python reserved word.' next to the
360 field.
361 This feature is meant as a shortcut, not as definitive model genera‐
363 tion. After you run it, you'll want to look over the generated models
364 yourself to make customizations. In particular, you'll need to rear‐
365 range models' order, so that models that refer to other models are
366 ordered properly.
367 Primary keys are automatically introspected for PostgreSQL, MySQL and
369 SQLite, in which case Django puts in the primary_key=True where needed.
370 inspectdb works with PostgreSQL, MySQL and SQLite. Foreign-key detec‐
372 tion only works in PostgreSQL and with certain types of MySQL tables.
373 Django doesn't create database defaults when a default is specified on
375 a model field. Similarly, database defaults aren't translated to model
376 field defaults or detected in any fashion by inspectdb.
377 By default, inspectdb creates unmanaged models. That is, managed =
379 False in the model's Meta class tells Django not to manage each table's
380 creation, modification, and deletion. If you do want to allow Django to
381 manage the table's lifecycle, you'll need to change the managed option
382 to True (or simply remove it because True is its default value).
383 --database DATABASE
385 Specifies the database to introspect. Defaults to default.
387 --include-views
389 If this option is provided, models are also created for database views.
393 loaddata
395 django-admin loaddata fixture [fixture ...]
396 Searches for and loads the contents of the named fixture into the data‐
398 base.
399 --database DATABASE
401 Specifies the database into which the data will be loaded. Defaults to
403 default.
404 --ignorenonexistent, -i
406 Ignores fields and models that may have been removed since the fixture
408 was originally generated.
409 --app APP_LABEL
411 Specifies a single app to look for fixtures in rather than looking in
413 all apps.
414 --format FORMAT
416 Specifies the serialization format (e.g., json or xml) for fixtures
420 read from stdin.
421 --exclude EXCLUDE, -e EXCLUDE
423 Excludes loading the fixtures from the given applications and/or models
425 (in the form of app_label or app_label.ModelName). Use the option mul‐
426 tiple times to exclude more than one app or model.
427 What's a fixture ?
429 A fixture is a collection of files that contain the serialized contents
430 of the database. Each fixture has a unique name, and the files that
431 comprise the fixture can be distributed over multiple directories, in
432 multiple applications.
433 Django will search in three locations for fixtures:
435 1. In the fixtures directory of every installed application
437 2. In any directory named in the FIXTURE_DIRS setting
439 3. In the literal path named by the fixture
441 Django will load any and all fixtures it finds in these locations that
443 match the provided fixture names.
444 If the named fixture has a file extension, only fixtures of that type
446 will be loaded. For example:
447 django-admin loaddata mydata.json
449 would only load JSON fixtures called mydata. The fixture extension must
451 correspond to the registered name of a serializer (e.g., json or xml).
452 If you omit the extensions, Django will search all available fixture
454 types for a matching fixture. For example:
455 django-admin loaddata mydata
457 would look for any fixture of any fixture type called mydata. If a fix‐
459 ture directory contained mydata.json, that fixture would be loaded as a
460 JSON fixture.
461 The fixtures that are named can include directory components. These
463 directories will be included in the search path. For example:
464 django-admin loaddata foo/bar/mydata.json
466 would search <app_label>/fixtures/foo/bar/mydata.json for each
468 installed application, <dirname>/foo/bar/mydata.json for each direc‐
469 tory in FIXTURE_DIRS, and the literal path foo/bar/mydata.json.
470 When fixture files are processed, the data is saved to the database as
472 is. Model defined save() methods are not called, and any pre_save or
473 post_save signals will be called with raw=True since the instance only
474 contains attributes that are local to the model. You may, for example,
475 want to disable handlers that access related fields that aren't present
476 during fixture loading and would otherwise raise an exception:
477 from django.db.models.signals import post_save
479 from .models import MyModel
480 def my_handler(**kwargs):
482 # disable the handler during fixture loading
483 if kwargs['raw']:
484 return
485 ...
486 post_save.connect(my_handler, sender=MyModel)
488 You could also write a simple decorator to encapsulate this logic:
490 from functools import wraps
492 def disable_for_loaddata(signal_handler):
494 """
495 Decorator that turns off signal handlers when loading fixture data.
496 """
497 @wraps(signal_handler)
498 def wrapper(*args, **kwargs):
499 if kwargs['raw']:
500 return
501 signal_handler(*args, **kwargs)
502 return wrapper
503 @disable_for_loaddata
505 def my_handler(**kwargs):
506 ...
507 Just be aware that this logic will disable the signals whenever fix‐
509 tures are deserialized, not just during loaddata.
510 Note that the order in which fixture files are processed is undefined.
512 However, all fixture data is installed as a single transaction, so data
513 in one fixture can reference data in another fixture. If the database
514 backend supports row-level constraints, these constraints will be
515 checked at the end of the transaction.
516 The dumpdata command can be used to generate input for loaddata.
518 Compressed fixtures
520 Fixtures may be compressed in zip, gz, or bz2 format. For example:
521 django-admin loaddata mydata.json
523 would look for any of mydata.json, mydata.json.zip, mydata.json.gz, or
525 mydata.json.bz2. The first file contained within a zip-compressed ar‐
526 chive is used.
527 Note that if two fixtures with the same name but different fixture type
529 are discovered (for example, if mydata.json and mydata.xml.gz were
530 found in the same fixture directory), fixture installation will be
531 aborted, and any data installed in the call to loaddata will be removed
532 from the database.
533 MySQL with MyISAM and fixtures
535 The MyISAM storage engine of MySQL doesn't support transac‐
537 tions or constraints, so if you use MyISAM, you won't get
538 validation of fixture data, or a rollback if multiple trans‐
539 action files are found.
540 Database-specific fixtures
542 If you're in a multi-database setup, you might have fixture data that
543 you want to load onto one database, but not onto another. In this situ‐
544 ation, you can add a database identifier into the names of your fix‐
545 tures.
546 For example, if your DATABASES setting has a 'master' database defined,
548 name the fixture mydata.master.json or mydata.master.json.gz and the
549 fixture will only be loaded when you specify you want to load data into
550 the master database.
551 Loading fixtures from stdin
553 You can use a dash as the fixture name to load input from sys.stdin.
554 For example:
555 django-admin loaddata --format=json -
557 When reading from stdin, the --format option is required to specify the
559 serialization format of the input (e.g., json or xml).
560 Loading from stdin is useful with standard input and output redirec‐
562 tions. For example:
563 django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -
565 makemessages
567 django-admin makemessages
568 Runs over the entire source tree of the current directory and pulls out
570 all strings marked for translation. It creates (or updates) a message
571 file in the conf/locale (in the Django tree) or locale (for project and
572 application) directory. After making changes to the messages files you
573 need to compile them with compilemessages for use with the builtin get‐
574 text support. See the i18n documentation for details.
575 This command doesn't require configured settings. However, when set‐
577 tings aren't configured, the command can't ignore the MEDIA_ROOT and
578 STATIC_ROOT directories or include LOCALE_PATHS. It will also write
579 files in UTF-8 rather than in FILE_CHARSET.
580 --all, -a
582 Updates the message files for all available languages.
584 --extension EXTENSIONS, -e EXTENSIONS
586 Specifies a list of file extensions to examine (default: html, txt, py
588 or js if --domain is js).
589 Example usage:
591 django-admin makemessages --locale=de --extension xhtml
593 Separate multiple extensions with commas or use -e or --extension mul‐
595 tiple times:
596 django-admin makemessages --locale=de --extension=html,txt --extension xml
598 --locale LOCALE, -l LOCALE
600 Specifies the locale(s) to process.
602 --exclude EXCLUDE, -x EXCLUDE
604 Specifies the locale(s) to exclude from processing. If not provided, no
606 locales are excluded.
607 Example usage:
609 django-admin makemessages --locale=pt_BR
611 django-admin makemessages --locale=pt_BR --locale=fr
612 django-admin makemessages -l pt_BR
613 django-admin makemessages -l pt_BR -l fr
614 django-admin makemessages --exclude=pt_BR
615 django-admin makemessages --exclude=pt_BR --exclude=fr
616 django-admin makemessages -x pt_BR
617 django-admin makemessages -x pt_BR -x fr
618 --domain DOMAIN, -d DOMAIN
620 Specifies the domain of the messages files. Supported options are:
622 · django for all *.py, *.html and *.txt files (default)
624 · djangojs for *.js files
626 --symlinks, -s
628 Follows symlinks to directories when looking for new translation
630 strings.
631 Example usage:
633 django-admin makemessages --locale=de --symlinks
635 --ignore PATTERN, -i PATTERN
637 Ignores files or directories matching the given glob-style pattern. Use
639 multiple times to ignore more.
640 These patterns are used by default: 'CVS', '.*', '*~', '*.pyc'.
642 Example usage:
644 django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html
646 --no-default-ignore
648 Disables the default values of --ignore.
650 --no-wrap
652 Disables breaking long message lines into several lines in language
654 files.
655 --no-location
657 Suppresses writing '#: filename:line’ comment lines in language files.
659 Using this option makes it harder for technically skilled translators
660 to understand each message's context.
661 --add-location [{full,file,never}]
663 Controls #: filename:line comment lines in language files. If the
667 option is:
668 · full (the default if not given): the lines include both file name and
670 line number.
671 · file: the line number is omitted.
673 · never: the lines are suppressed (same as --no-location).
675 Requires gettext 0.19 or newer.
677 --keep-pot
679 Prevents deleting the temporary .pot files generated before creating
681 the .po file. This is useful for debugging errors which may prevent the
682 final language files from being created.
683 SEE ALSO:
685 See customizing-makemessages for instructions on how to customize
686 the keywords that makemessages passes to xgettext.
687 makemigrations
689 django-admin makemigrations [app_label [app_label ...]]
690 Creates new migrations based on the changes detected to your models.
692 Migrations, their relationship with apps and more are covered in depth
693 in the migrations documentation.
694 Providing one or more app names as arguments will limit the migrations
696 created to the app(s) specified and any dependencies needed (the table
697 at the other end of a ForeignKey, for example).
698 To add migrations to an app that doesn't have a migrations directory,
700 run makemigrations with the app's app_label.
701 --noinput, --no-input
703 Suppresses all user prompts. If a suppressed prompt cannot be resolved
705 automatically, the command will exit with error code 3.
706 --empty
708 Outputs an empty migration for the specified apps, for manual editing.
710 This is for advanced users and should not be used unless you are famil‐
711 iar with the migration format, migration operations, and the dependen‐
712 cies between your migrations.
713 --dry-run
715 Shows what migrations would be made without actually writing any migra‐
717 tions files to disk. Using this option along with --verbosity 3 will
718 also show the complete migrations files that would be written.
719 --merge
721 Enables fixing of migration conflicts.
723 --name NAME, -n NAME
725 Allows naming the generated migration(s) instead of using a generated
727 name.
728 --check
730 Makes makemigrations exit with a non-zero status when model changes
732 without migrations are detected.
733 migrate
735 django-admin migrate [app_label] [migration_name]
736 Synchronizes the database state with the current set of models and
738 migrations. Migrations, their relationship with apps and more are cov‐
739 ered in depth in the migrations documentation.
740 The behavior of this command changes depending on the arguments pro‐
742 vided:
743 · No arguments: All apps have all of their migrations run.
745 · <app_label>: The specified app has its migrations run, up to the most
747 recent migration. This may involve running other apps' migrations
748 too, due to dependencies.
749 · <app_label> <migrationname>: Brings the database schema to a state
751 where the named migration is applied, but no later migrations in the
752 same app are applied. This may involve unapplying migrations if you
753 have previously migrated past the named migration. Use the name zero
754 to unapply all migrations for an app.
755 --database DATABASE
757 Specifies the database to migrate. Defaults to default.
759 --fake
761 Marks the migrations up to the target one (following the rules above)
763 as applied, but without actually running the SQL to change your data‐
764 base schema.
765 This is intended for advanced users to manipulate the current migration
767 state directly if they're manually applying changes; be warned that
768 using --fake runs the risk of putting the migration state table into a
769 state where manual recovery will be needed to make migrations run cor‐
770 rectly.
771 --fake-initial
773 Allows Django to skip an app's initial migration if all database tables
775 with the names of all models created by all CreateModel operations in
776 that migration already exist. This option is intended for use when
777 first running migrations against a database that preexisted the use of
778 migrations. This option does not, however, check for matching database
779 schema beyond matching table names and so is only safe to use if you
780 are confident that your existing schema matches what is recorded in
781 your initial migration.
782 --run-syncdb
784 Allows creating tables for apps without migrations. While this isn't
786 recommended, the migrations framework is sometimes too slow on large
787 projects with hundreds of models.
788 --noinput, --no-input
790 Suppresses all user prompts. An example prompt is asking about removing
792 stale content types.
793 runserver
795 django-admin runserver [addrport]
796 Starts a lightweight development Web server on the local machine. By
798 default, the server runs on port 8000 on the IP address 127.0.0.1. You
799 can pass in an IP address and port number explicitly.
800 If you run this script as a user with normal privileges (recommended),
802 you might not have access to start a port on a low port number. Low
803 port numbers are reserved for the superuser (root).
804 This server uses the WSGI application object specified by the
806 WSGI_APPLICATION setting.
807 DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through
809 security audits or performance tests. (And that's how it's gonna stay.
810 We're in the business of making Web frameworks, not Web servers, so
811 improving this server to be able to handle a production environment is
812 outside the scope of Django.)
813 The development server automatically reloads Python code for each
815 request, as needed. You don't need to restart the server for code
816 changes to take effect. However, some actions like adding files don't
817 trigger a restart, so you'll have to restart the server in these cases.
818 If you are using Linux and install pyinotify, kernel signals will be
820 used to autoreload the server (rather than polling file modification
821 timestamps each second). This offers better scaling to large projects,
822 reduction in response time to code modification, more robust change
823 detection, and battery usage reduction.
824 When you start the server, and each time you change Python code while
826 the server is running, the system check framework will check your
827 entire Django project for some common errors (see the check command).
828 If any errors are found, they will be printed to standard output.
829 You can run as many concurrent servers as you want, as long as they're
831 on separate ports. Just execute django-admin runserver more than once.
832 Note that the default IP address, 127.0.0.1, is not accessible from
834 other machines on your network. To make your development server view‐
835 able to other machines on the network, use its own IP address (e.g.
836 192.168.2.1) or 0.0.0.0 or :: (with IPv6 enabled).
837 You can provide an IPv6 address surrounded by brackets (e.g.
839 [200a::1]:8000). This will automatically enable IPv6 support.
840 A hostname containing ASCII-only characters can also be used.
842 If the staticfiles contrib app is enabled (default in new projects) the
844 runserver command will be overridden with its own runserver command.
845 Logging of each request and response of the server is sent to the
847 django-server-logger logger.
848 --noreload
850 Disables the auto-reloader. This means any Python code changes you make
852 while the server is running will not take effect if the particular
853 Python modules have already been loaded into memory.
854 --nothreading
856 Disables use of threading in the development server. The server is mul‐
858 tithreaded by default.
859 --ipv6, -6
861 Uses IPv6 for the development server. This changes the default IP
863 address from 127.0.0.1 to ::1.
864 Examples of using different ports and addresses
866 Port 8000 on IP address 127.0.0.1:
867 django-admin runserver
869 Port 8000 on IP address 1.2.3.4:
871 django-admin runserver 1.2.3.4:8000
873 Port 7000 on IP address 127.0.0.1:
875 django-admin runserver 7000
877 Port 7000 on IP address 1.2.3.4:
879 django-admin runserver 1.2.3.4:7000
881 Port 8000 on IPv6 address ::1:
883 django-admin runserver -6
885 Port 7000 on IPv6 address ::1:
887 django-admin runserver -6 7000
889 Port 7000 on IPv6 address 2001:0db8:1234:5678::9:
891 django-admin runserver [2001:0db8:1234:5678::9]:7000
893 Port 8000 on IPv4 address of host localhost:
895 django-admin runserver localhost:8000
897 Port 8000 on IPv6 address of host localhost:
899 django-admin runserver -6 localhost:8000
901 Serving static files with the development server
903 By default, the development server doesn't serve any static files for
904 your site (such as CSS files, images, things under MEDIA_URL and so
905 forth). If you want to configure Django to serve static media, read
906 /howto/static-files/index.
907 sendtestemail
909 django-admin sendtestemail [email [email ...]]
910 Sends a test email (to confirm email sending through Django is working)
912 to the recipient(s) specified. For example:
913 django-admin sendtestemail foo@example.com bar@example.com
915 There are a couple of options, and you may use any combination of them
917 together:
918 --managers
920 Mails the email addresses specified in MANAGERS using mail_managers().
922 --admins
924 Mails the email addresses specified in ADMINS using mail_admins().
926 shell
928 django-admin shell
929 Starts the Python interactive interpreter.
931 --interface {ipython,bpython,python}, -i {ipython,bpython,python}
933 Specifies the shell to use. By default, Django will use IPython or
935 bpython if either is installed. If both are installed, specify which
936 one you want like so:
937 IPython:
939 django-admin shell -i ipython
941 bpython:
943 django-admin shell -i bpython
945 If you have a "rich" shell installed but want to force use of the
947 "plain" Python interpreter, use python as the interface name, like so:
948 django-admin shell -i python
950 --nostartup
952 Disables reading the startup script for the "plain" Python interpreter.
954 By default, the script pointed to by the PYTHONSTARTUP environment
955 variable or the ~/.pythonrc.py script is read.
956 --command COMMAND, -c COMMAND
958 Lets you pass a command as a string to execute it as Django, like so:
960 django-admin shell --command="import django; print(django.__version__)"
962 You can also pass code in on standard input to execute it. For example:
964 $ django-admin shell <<EOF
966 > import django
967 > print(django.__version__)
968 > EOF
969 On Windows, the REPL is output due to implementation limits of
971 select.select() on that platform.
972 showmigrations
974 django-admin showmigrations [app_label [app_label ...]]
975 Shows all migrations in a project. You can choose from one of two for‐
977 mats:
978 --list, -l
980 Lists all of the apps Django knows about, the migrations available for
982 each app, and whether or not each migration is applied (marked by an
983 [X] next to the migration name).
984 Apps without migrations are also listed, but have (no migrations)
986 printed under them.
987 This is the default output format.
989 --plan, -p
991 Shows the migration plan Django will follow to apply migrations. Like
993 --list, applied migrations are marked by an [X]. For a --verbosity of 2
994 and above, all dependencies of a migration will also be shown.
995 app_labels arguments limit the output, however, dependencies of pro‐
997 vided apps may also be included.
998 --database DATABASE
1000 Specifies the database to examine. Defaults to default.
1002 sqlflush
1004 django-admin sqlflush
1005 Prints the SQL statements that would be executed for the flush command.
1007 --database DATABASE
1009 Specifies the database for which to print the SQL. Defaults to default.
1011 sqlmigrate
1013 django-admin sqlmigrate app_label migration_name
1014 Prints the SQL for the named migration. This requires an active data‐
1016 base connection, which it will use to resolve constraint names; this
1017 means you must generate the SQL against a copy of the database you wish
1018 to later apply it on.
1019 Note that sqlmigrate doesn't colorize its output.
1021 --backwards
1023 Generates the SQL for unapplying the migration. By default, the SQL
1025 created is for running the migration in the forwards direction.
1026 --database DATABASE
1028 Specifies the database for which to generate the SQL. Defaults to
1030 default.
1031 sqlsequencereset
1033 django-admin sqlsequencereset app_label [app_label ...]
1034 Prints the SQL statements for resetting sequences for the given app
1036 name(s).
1037 Sequences are indexes used by some database engines to track the next
1039 available number for automatically incremented fields.
1040 Use this command to generate SQL which will fix cases where a sequence
1042 is out of sync with its automatically incremented field data.
1043 --database DATABASE
1045 Specifies the database for which to print the SQL. Defaults to default.
1047 squashmigrations
1049 django-admin squashmigrations app_label [start_migration_name] migra‐
1050 tion_name
1051 Squashes the migrations for app_label up to and including migra‐
1053 tion_name down into fewer migrations, if possible. The resulting
1054 squashed migrations can live alongside the unsquashed ones safely. For
1055 more information, please read migration-squashing.
1056 When start_migration_name is given, Django will only include migrations
1058 starting from and including this migration. This helps to mitigate the
1059 squashing limitation of RunPython and django.db.migrations.opera‐
1060 tions.RunSQL migration operations.
1061 --no-optimize
1063 Disables the optimizer when generating a squashed migration. By
1065 default, Django will try to optimize the operations in your migrations
1066 to reduce the size of the resulting file. Use this option if this
1067 process is failing or creating incorrect migrations, though please also
1068 file a Django bug report about the behavior, as optimization is meant
1069 to be safe.
1070 --noinput, --no-input
1072 Suppresses all user prompts.
1074 --squashed-name SQUASHED_NAME
1076 Sets the name of the squashed migration. When omitted, the name is
1080 based on the first and last migration, with _squashed_ in between.
1081 startapp
1083 django-admin startapp name [directory]
1084 Creates a Django app directory structure for the given app name in the
1086 current directory or the given destination.
1087 By default the directory created contains a models.py file and other
1089 app template files. (See the source for more details.) If only the app
1090 name is given, the app directory will be created in the current working
1091 directory.
1092 If the optional destination is provided, Django will use that existing
1094 directory rather than creating a new one. You can use '.' to denote the
1095 current working directory.
1096 For example:
1098 django-admin startapp myapp /Users/jezdez/Code/myapp
1100 --template TEMPLATE
1102 Provides the path to a directory with a custom app template file or a
1104 path to a compressed file (.tar.gz, .tar.bz2, .tgz, .tbz, .zip) con‐
1105 taining the app template files.
1106 For example, this would look for an app template in the given directory
1108 when creating the myapp app:
1109 django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp
1111 Django will also accept URLs (http, https, ftp) to compressed archives
1113 with the app template files, downloading and extracting them on the
1114 fly.
1115 For example, taking advantage of GitHub's feature to expose reposito‐
1117 ries as zip files, you can use a URL like:
1118 django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip myapp
1120 --extension EXTENSIONS, -e EXTENSIONS
1122 Specifies which file extensions in the app template should be rendered
1124 with the template engine. Defaults to py.
1125 --name FILES, -n FILES
1127 Specifies which files in the app template (in addition to those match‐
1129 ing --extension) should be rendered with the template engine. Defaults
1130 to an empty list.
1131 The template context used for all matching files is:
1133 · Any option passed to the startapp command (among the command's sup‐
1135 ported options)
1136 · app_name -- the app name as passed to the command
1138 · app_directory -- the full path of the newly created app
1140 · camel_case_app_name -- the app name in camel case format
1142 · docs_version -- the version of the documentation: 'dev' or '1.x'
1144 · django_version -- the version of Django, e.g.``'2.0.3'``
1146 WARNING:
1148 When the app template files are rendered with the Django template
1149 engine (by default all *.py files), Django will also replace all
1150 stray template variables contained. For example, if one of the
1151 Python files contains a docstring explaining a particular feature
1152 related to template rendering, it might result in an incorrect exam‐
1153 ple.
1154 To work around this problem, you can use the templatetag template
1156 tag to "escape" the various parts of the template syntax.
1157 In addition, to allow Python template files that contain Django tem‐
1159 plate language syntax while also preventing packaging systems from
1160 trying to byte-compile invalid *.py files, template files ending
1161 with .py-tpl will be renamed to .py.
1162 startproject
1164 django-admin startproject name [directory]
1165 Creates a Django project directory structure for the given project name
1167 in the current directory or the given destination.
1168 By default, the new directory contains manage.py and a project package
1170 (containing a settings.py and other files). See the template source for
1171 details.
1172 If only the project name is given, both the project directory and
1174 project package will be named <projectname> and the project directory
1175 will be created in the current working directory.
1176 If the optional destination is provided, Django will use that existing
1178 directory as the project directory, and create manage.py and the
1179 project package within it. Use '.' to denote the current working direc‐
1180 tory.
1181 For example:
1183 django-admin startproject myproject /Users/jezdez/Code/myproject_repo
1185 --template TEMPLATE
1187 Specifies a directory, file path, or URL of a custom project template.
1189 See the startapp --template documentation for examples and usage.
1190 --extension EXTENSIONS, -e EXTENSIONS
1192 Specifies which file extensions in the project template should be ren‐
1194 dered with the template engine. Defaults to py.
1195 --name FILES, -n FILES
1197 Specifies which files in the project template (in addition to those
1199 matching --extension) should be rendered with the template engine.
1200 Defaults to an empty list.
1201 The template context used is:
1203 · Any option passed to the startproject command (among the command's
1205 supported options)
1206 · project_name -- the project name as passed to the command
1208 · project_directory -- the full path of the newly created project
1210 · secret_key -- a random key for the SECRET_KEY setting
1212 · docs_version -- the version of the documentation: 'dev' or '1.x'
1214 · django_version -- the version of Django, e.g.``'2.0.3'``
1216 Please also see the rendering warning as mentioned for startapp.
1218 test
1220 django-admin test [test_label [test_label ...]]
1221 Runs tests for all installed apps. See /topics/testing/index for more
1223 information.
1224 --failfast
1226 Stops running tests and reports the failure immediately after a test
1228 fails.
1229 --testrunner TESTRUNNER
1231 Controls the test runner class that is used to execute tests. This
1233 value overrides the value provided by the TEST_RUNNER setting.
1234 --noinput, --no-input
1236 Suppresses all user prompts. A typical prompt is a warning about delet‐
1238 ing an existing test database.
1239 Test runner options
1241 The test command receives options on behalf of the specified
1242 --testrunner. These are the options of the default test runner: Discov‐
1243 erRunner.
1244 --keepdb, -k
1246 Preserves the test database between test runs. This has the advantage
1248 of skipping both the create and destroy actions which can greatly
1249 decrease the time to run tests, especially those in a large test suite.
1250 If the test database does not exist, it will be created on the first
1251 run and then preserved for each subsequent run. Any unapplied migra‐
1252 tions will also be applied to the test database before running the test
1253 suite.
1254 --reverse, -r
1256 Sorts test cases in the opposite execution order. This may help in
1258 debugging the side effects of tests that aren't properly isolated.
1259 Grouping by test class is preserved when using this option.
1260 --debug-mode
1262 Sets the DEBUG setting to True prior to running tests. This may help
1264 troubleshoot test failures.
1265 --debug-sql, -d
1267 Enables SQL logging for failing tests. If --verbosity is 2, then
1269 queries in passing tests are also output.
1270 --parallel [N]
1272 Runs tests in separate parallel processes. Since modern processors have
1274 multiple cores, this allows running tests significantly faster.
1275 By default --parallel runs one process per core according to
1277 multiprocessing.cpu_count(). You can adjust the number of processes
1278 either by providing it as the option's value, e.g. --parallel=4, or by
1279 setting the DJANGO_TEST_PROCESSES environment variable.
1280 Django distributes test cases — unittest.TestCase subclasses — to sub‐
1282 processes. If there are fewer test cases than configured processes,
1283 Django will reduce the number of processes accordingly.
1284 Each process gets its own database. You must ensure that different test
1286 cases don't access the same resources. For instance, test cases that
1287 touch the filesystem should create a temporary directory for their own
1288 use.
1289 This option requires the third-party tblib package to display trace‐
1291 backs correctly:
1292 $ pip install tblib
1294 This feature isn't available on Windows. It doesn't work with the Ora‐
1296 cle database backend either.
1297 If you want to use pdb while debugging tests, you must disable parallel
1299 execution (--parallel=1). You'll see something like bdb.BdbQuit if you
1300 don't.
1301 WARNING:
1303 When test parallelization is enabled and a test fails, Django may be
1304 unable to display the exception traceback. This can make debugging
1305 difficult. If you encounter this problem, run the affected test
1306 without parallelization to see the traceback of the failure.
1307 This is a known limitation. It arises from the need to serialize
1309 objects in order to exchange them between processes. See What can be
1310 pickled and unpickled? for details.
1311 --tag TAGS
1313 Runs only tests marked with the specified tags. May be specified mul‐
1315 tiple times and combined with test --exclude-tag.
1316 --exclude-tag EXCLUDE_TAGS
1318 Excludes tests marked with the specified tags. May be specified multi‐
1320 ple times and combined with test --tag.
1321 testserver
1323 django-admin testserver [fixture [fixture ...]]
1324 Runs a Django development server (as in runserver) using data from the
1326 given fixture(s).
1327 For example, this command:
1329 django-admin testserver mydata.json
1331 ...would perform the following steps:
1333 1. Create a test database, as described in the-test-database.
1335 2. Populate the test database with fixture data from the given fix‐
1337 tures. (For more on fixtures, see the documentation for loaddata
1338 above.)
1339 3. Runs the Django development server (as in runserver), pointed at
1341 this newly created test database instead of your production data‐
1342 base.
1343 This is useful in a number of ways:
1345 · When you're writing unit tests of how your views act with certain
1347 fixture data, you can use testserver to interact with the views in a
1348 Web browser, manually.
1349 · Let's say you're developing your Django application and have a "pris‐
1351 tine" copy of a database that you'd like to interact with. You can
1352 dump your database to a fixture (using the dumpdata command,
1353 explained above), then use testserver to run your Web application
1354 with that data. With this arrangement, you have the flexibility of
1355 messing up your data in any way, knowing that whatever data changes
1356 you're making are only being made to a test database.
1357 Note that this server does not automatically detect changes to your
1359 Python source code (as runserver does). It does, however, detect
1360 changes to templates.
1361 --addrport ADDRPORT
1363 Specifies a different port, or IP address and port, from the default of
1365 127.0.0.1:8000. This value follows exactly the same format and serves
1366 exactly the same function as the argument to the runserver command.
1367 Examples:
1369 To run the test server on port 7000 with fixture1 and fixture2:
1371 django-admin testserver --addrport 7000 fixture1 fixture2
1373 django-admin testserver fixture1 fixture2 --addrport 7000
1374 (The above statements are equivalent. We include both of them to demon‐
1376 strate that it doesn't matter whether the options come before or after
1377 the fixture arguments.)
1378 To run on 1.2.3.4:7000 with a test fixture:
1380 django-admin testserver --addrport 1.2.3.4:7000 test
1382 --noinput, --no-input
1384 Suppresses all user prompts. A typical prompt is a warning about delet‐
1386 ing an existing test database.
1387
1389 Some commands are only available when the django.contrib application
1390 that implements them has been enabled. This section describes them
1391 grouped by their application.
1392 django.contrib.auth
1394 changepassword
1395 django-admin changepassword [<username>]
1396 This command is only available if Django's authentication system
1398 (django.contrib.auth) is installed.
1399 Allows changing a user's password. It prompts you to enter a new pass‐
1401 word twice for the given user. If the entries are identical, this imme‐
1402 diately becomes the new password. If you do not supply a user, the com‐
1403 mand will attempt to change the password whose username matches the
1404 current user.
1405 --database DATABASE
1407 Specifies the database to query for the user. Defaults to default.
1409 Example usage:
1411 django-admin changepassword ringo
1413 createsuperuser
1415 django-admin createsuperuser
1416 This command is only available if Django's authentication system
1418 (django.contrib.auth) is installed.
1419 Creates a superuser account (a user who has all permissions). This is
1421 useful if you need to create an initial superuser account or if you
1422 need to programmatically generate superuser accounts for your site(s).
1423 When run interactively, this command will prompt for a password for the
1425 new superuser account. When run non-interactively, no password will be
1426 set, and the superuser account will not be able to log in until a pass‐
1427 word has been manually set for it.
1428 --username USERNAME
1430 --email EMAIL
1432 The username and email address for the new account can be supplied by
1434 using the --username and --email arguments on the command line. If
1435 either of those is not supplied, createsuperuser will prompt for it
1436 when running interactively.
1437 --database DATABASE
1439 Specifies the database into which the superuser object will be saved.
1441 You can subclass the management command and override get_input_data()
1443 if you want to customize data input and validation. Consult the source
1444 code for details on the existing implementation and the method's param‐
1445 eters. For example, it could be useful if you have a ForeignKey in
1446 REQUIRED_FIELDS and want to allow creating an instance instead of
1447 entering the primary key of an existing instance.
1448 django.contrib.contenttypes
1450 remove_stale_contenttypes
1451 django-admin remove_stale_contenttypes
1452 This command is only available if Django's contenttypes app
1454 (django.contrib.contenttypes) is installed.
1455 Deletes stale content types (from deleted models) in your database. Any
1457 objects that depend on the deleted content types will also be deleted.
1458 A list of deleted objects will be displayed before you confirm it's
1459 okay to proceed with the deletion.
1460 --database DATABASE
1462 Specifies the database to use. Defaults to default.
1464 django.contrib.gis
1466 ogrinspect
1467 This command is only available if GeoDjango (django.contrib.gis) is
1468 installed.
1469 Please refer to its description in the GeoDjango documentation.
1471 django.contrib.sessions
1473 clearsessions
1474 django-admin clearsessions
1475 Can be run as a cron job or directly to clean out expired sessions.
1477 django.contrib.sitemaps
1479 ping_google
1480 This command is only available if the Sitemaps framework (django.con‐
1481 trib.sitemaps) is installed.
1482 Please refer to its description in the Sitemaps documentation.
1484 django.contrib.staticfiles
1486 collectstatic
1487 This command is only available if the static files application
1488 (django.contrib.staticfiles) is installed.
1489 Please refer to its description in the staticfiles documentation.
1491 findstatic
1493 This command is only available if the static files application
1494 (django.contrib.staticfiles) is installed.
1495 Please refer to its description in the staticfiles documentation.
1497
1499 Although some commands may allow their own custom options, every com‐
1500 mand allows for the following options:
1501 --pythonpath PYTHONPATH
1503 Adds the given filesystem path to the Python import search path. If
1505 this isn't provided, django-admin will use the PYTHONPATH environment
1506 variable.
1507 This option is unnecessary in manage.py, because it takes care of set‐
1509 ting the Python path for you.
1510 Example usage:
1512 django-admin migrate --pythonpath='/home/djangoprojects/myproject'
1514 --settings SETTINGS
1516 Specifies the settings module to use. The settings module should be in
1518 Python package syntax, e.g. mysite.settings. If this isn't provided,
1519 django-admin will use the DJANGO_SETTINGS_MODULE environment variable.
1520 This option is unnecessary in manage.py, because it uses settings.py
1522 from the current project by default.
1523 Example usage:
1525 django-admin migrate --settings=mysite.settings
1527 --traceback
1529 Displays a full stack trace when a CommandError is raised. By default,
1531 django-admin will show a simple error message when a CommandError
1532 occurs and a full stack trace for any other exception.
1533 Example usage:
1535 django-admin migrate --traceback
1537 --verbosity {0,1,2,3}, -v {0,1,2,3}
1539 Specifies the amount of notification and debug information that a com‐
1541 mand should print to the console.
1542 · 0 means no output.
1544 · 1 means normal output (default).
1546 · 2 means verbose output.
1548 · 3 means very verbose output.
1550 Example usage:
1552 django-admin migrate --verbosity 2
1554 --no-color
1556 Disables colorized command output. Some commands format their output
1558 to be colorized. For example, errors will be printed to the console in
1559 red and SQL statements will be syntax highlighted.
1560 Example usage:
1562 django-admin runserver --no-color
1564
1566 Syntax coloring
1567 The django-admin / manage.py commands will use pretty color-coded out‐
1568 put if your terminal supports ANSI-colored output. It won't use the
1569 color codes if you're piping the command's output to another program.
1570 Under Windows, the native console doesn't support ANSI escape sequences
1572 so by default there is no color output. But you can install the ANSICON
1573 third-party tool, the Django commands will detect its presence and will
1574 make use of its services to color output just like on Unix-based plat‐
1575 forms.
1576 The colors used for syntax highlighting can be customized. Django ships
1578 with three color palettes:
1579 · dark, suited to terminals that show white text on a black background.
1581 This is the default palette.
1582 · light, suited to terminals that show black text on a white back‐
1584 ground.
1585 · nocolor, which disables syntax highlighting.
1587 You select a palette by setting a DJANGO_COLORS environment variable to
1589 specify the palette you want to use. For example, to specify the light
1590 palette under a Unix or OS/X BASH shell, you would run the following at
1591 a command prompt:
1592 export DJANGO_COLORS="light"
1594 You can also customize the colors that are used. Django specifies a
1596 number of roles in which color is used:
1597 · error - A major error.
1599 · notice - A minor error.
1601 · success - A success.
1603 · warning - A warning.
1605 · sql_field - The name of a model field in SQL.
1607 · sql_coltype - The type of a model field in SQL.
1609 · sql_keyword - An SQL keyword.
1611 · sql_table - The name of a model in SQL.
1613 · http_info - A 1XX HTTP Informational server response.
1615 · http_success - A 2XX HTTP Success server response.
1617 · http_not_modified - A 304 HTTP Not Modified server response.
1619 · http_redirect - A 3XX HTTP Redirect server response other than 304.
1621 · http_not_found - A 404 HTTP Not Found server response.
1623 · http_bad_request - A 4XX HTTP Bad Request server response other than
1625 404.
1626 · http_server_error - A 5XX HTTP Server Error response.
1628 · migrate_heading - A heading in a migrations management command.
1630 · migrate_label - A migration name.
1632 Each of these roles can be assigned a specific foreground and back‐
1634 ground color, from the following list:
1635 · black
1637 · red
1639 · green
1641 · yellow
1643 · blue
1645 · magenta
1647 · cyan
1649 · white
1651 Each of these colors can then be modified by using the following dis‐
1653 play options:
1654 · bold
1656 · underscore
1658 · blink
1660 · reverse
1662 · conceal
1664 A color specification follows one of the following patterns:
1666 · role=fg
1668 · role=fg/bg
1670 · role=fg,option,option
1672 · role=fg/bg,option,option
1674 where role is the name of a valid color role, fg is the foreground
1676 color, bg is the background color and each option is one of the color
1677 modifying options. Multiple color specifications are then separated by
1678 a semicolon. For example:
1679 export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
1681 would specify that errors be displayed using blinking yellow on blue,
1683 and notices displayed using magenta. All other color roles would be
1684 left uncolored.
1685 Colors can also be specified by extending a base palette. If you put a
1687 palette name in a color specification, all the colors implied by that
1688 palette will be loaded. So:
1689 export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
1691 would specify the use of all the colors in the light color palette,
1693 except for the colors for errors and notices which would be overridden
1694 as specified.
1695 Bash completion
1697 If you use the Bash shell, consider installing the Django bash comple‐
1698 tion script, which lives in extras/django_bash_completion in the Django
1699 source distribution. It enables tab-completion of django-admin and man‐
1700 age.py commands, so you can, for instance...
1701 · Type django-admin.
1703 · Press [TAB] to see all available options.
1705 · Type sql, then [TAB], to see all available options whose names start
1707 with sql.
1708 See /howto/custom-management-commands for how to add customized
1710 actions.
1711 django.core.management.call_command(name, *args, **options)
1713 To call a management command from code use call_command.
1715 name the name of the command to call or a command object. Passing the
1717 name is preferred unless the object is required for testing.
1718 *args a list of arguments accepted by the command. Arguments are
1720 passed to the argument parser, so you can use the same style as
1721 you would on the command line. For example, call_com‐
1722 mand('flush', '--verbosity=0').
1723 **options
1725 named options accepted on the command-line. Options are passed
1726 to the command without triggering the argument parser, which
1727 means you'll need to pass the correct type. For example,
1728 call_command('flush', verbosity=0) (zero must be an integer
1729 rather than a string).
1730 Examples:
1732 from django.core import management
1734 from django.core.management.commands import loaddata
1735 management.call_command('flush', verbosity=0, interactive=False)
1737 management.call_command('loaddata', 'test_data', verbosity=0)
1738 management.call_command(loaddata.Command(), 'test_data', verbosity=0)
1739 Note that command options that take no arguments are passed as keywords
1741 with True or False, as you can see with the interactive option above.
1742 Named arguments can be passed by using either one of the following syn‐
1744 taxes:
1745 # Similar to the command line
1747 management.call_command('dumpdata', '--natural-foreign')
1748 # Named argument similar to the command line minus the initial dashes and
1750 # with internal dashes replaced by underscores
1751 management.call_command('dumpdata', natural_foreign=True)
1752 # `use_natural_foreign_keys` is the option destination variable
1754 management.call_command('dumpdata', use_natural_foreign_keys=True)
1755 Some command options have different names when using call_command()
1757 instead of django-admin or manage.py. For example, django-admin create‐
1758 superuser --no-input translates to call_command('createsuperuser',
1759 interactive=False). To find what keyword argument name to use for
1760 call_command(), check the command's source code for the dest argument
1761 passed to parser.add_argument().
1762 Command options which take multiple options are passed a list:
1764 management.call_command('dumpdata', exclude=['contenttypes', 'auth'])
1766 The return value of the call_command() function is the same as the
1768 return value of the handle() method of the command.
1769
1771 Note that you can redirect standard output and error streams as all
1772 commands support the stdout and stderr options. For example, you could
1773 write:
1774 with open('/path/to/command_output') as f:
1776 management.call_command('dumpdata', stdout=f)
1777
1779 Django Software Foundation
1780
1782 Django Software Foundation and contributors
17832.1 May 17, 2018 DJANGO-ADMIN(1)