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 It does the same thing as django-admin but also sets the DJANGO_SET‐
13 TINGS_MODULE environment variable so that it points to your project's
14 settings.py file.
15 The django-admin script should be on your system path if you installed
17 Django via pip. If it's not in your path, ensure you have your virtual
18 environment activated.
19 Generally, when working on a single Django project, it's easier to use
21 manage.py than django-admin. If you need to switch between multiple
22 Django settings files, use django-admin with DJANGO_SETTINGS_MODULE or
23 the --settings command line option.
24 The command-line examples throughout this document use django-admin to
26 be consistent, but any example can use manage.py or python -m django
27 just as well.
28
30 $ django-admin <command> [options]
31 $ manage.py <command> [options]
32 $ python -m django <command> [options]
33 command should be one of the commands listed in this document. op‐
35 tions, which is optional, should be zero or more of the options avail‐
36 able for the given command.
37 Getting runtime help
39 django-admin help
40 Run django-admin help to display usage information and a list of the
42 commands provided by each application.
43 Run django-admin help --commands to display a list of all available
45 commands.
46 Run django-admin help <command> to display a description of the given
48 command and a list of its available options.
49 App names
51 Many commands take a list of "app names." An "app name" is the basename
52 of the package containing your models. For example, if your IN‐
53 STALLED_APPS contains the string 'mysite.blog', the app name is blog.
54 Determining the version
56 django-admin version
57 Run django-admin version to display the current Django version.
59 The output follows the schema described in PEP 440:
61 1.4.dev17026
63 1.4a1
64 1.4
65 Displaying debug output
67 Use --verbosity to specify the amount of notification and debug infor‐
68 mation that django-admin prints to the console.
69
71 check
72 django-admin check [app_label [app_label ...]]
73 Uses the system check framework to inspect the entire Django project
75 for common problems.
76 By default, all apps will be checked. You can check a subset of apps by
78 providing a list of app labels as arguments:
79 django-admin check auth admin myapp
81 --tag TAGS, -t TAGS
83 The system check framework performs many different types of checks that
85 are categorized with tags. You can use these tags to restrict the
86 checks performed to just those in a particular category. For example,
87 to perform only models and compatibility checks, run:
88 django-admin check --tag models --tag compatibility
90 --database DATABASE
92 Specifies the database to run checks requiring database access:
96 django-admin check --database default --database other
98 By default, these checks will not be run.
100 --list-tags
102 Lists all available tags.
104 --deploy
106 Activates some additional checks that are only relevant in a deployment
108 setting.
109 You can use this option in your local development environment, but
111 since your local development settings module may not have many of your
112 production settings, you will probably want to point the check command
113 at a different settings module, either by setting the DJANGO_SET‐
114 TINGS_MODULE environment variable, or by passing the --settings option:
115 django-admin check --deploy --settings=production_settings
117 Or you could run it directly on a production or staging deployment to
119 verify that the correct settings are in use (omitting --settings). You
120 could even make it part of your integration test suite.
121 --fail-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}
123 Specifies the message level that will cause the command to exit with a
125 non-zero status. Default is ERROR.
126 compilemessages
128 django-admin compilemessages
129 Compiles .po files created by makemessages to .mo files for use with
131 the built-in gettext support. See /topics/i18n/index.
132 --locale LOCALE, -l LOCALE
134 Specifies the locale(s) to process. If not provided, all locales are
136 processed.
137 --exclude EXCLUDE, -x EXCLUDE
139 Specifies the locale(s) to exclude from processing. If not provided, no
141 locales are excluded.
142 --use-fuzzy, -f
144 Includes fuzzy translations into compiled files.
146 Example usage:
148 django-admin compilemessages --locale=pt_BR
150 django-admin compilemessages --locale=pt_BR --locale=fr -f
151 django-admin compilemessages -l pt_BR
152 django-admin compilemessages -l pt_BR -l fr --use-fuzzy
153 django-admin compilemessages --exclude=pt_BR
154 django-admin compilemessages --exclude=pt_BR --exclude=fr
155 django-admin compilemessages -x pt_BR
156 django-admin compilemessages -x pt_BR -x fr
157 --ignore PATTERN, -i PATTERN
159 Ignores directories matching the given glob-style pattern. Use multiple
161 times to ignore more.
162 Example usage:
164 django-admin compilemessages --ignore=cache --ignore=outdated/*/locale
166 createcachetable
168 django-admin createcachetable
169 Creates the cache tables for use with the database cache backend using
171 the information from your settings file. See /topics/cache for more in‐
172 formation.
173 --database DATABASE
175 Specifies the database in which the cache table(s) will be created. De‐
177 faults to default.
178 --dry-run
180 Prints the SQL that would be run without actually running it, so you
182 can customize it or use the migrations framework.
183 dbshell
185 django-admin dbshell
186 Runs the command-line client for the database engine specified in your
188 ENGINE setting, with the connection parameters specified in your USER,
189 PASSWORD, etc., settings.
190 • For PostgreSQL, this runs the psql command-line client.
192 • For MySQL, this runs the mysql command-line client.
194 • For SQLite, this runs the sqlite3 command-line client.
196 • For Oracle, this runs the sqlplus command-line client.
198 This command assumes the programs are on your PATH so that a call to
200 the program name (psql, mysql, sqlite3, sqlplus) will find the program
201 in the right place. There's no way to specify the location of the pro‐
202 gram manually.
203 --database DATABASE
205 Specifies the database onto which to open a shell. Defaults to default.
207 -- ARGUMENTS
209 Any arguments following a -- divider will be passed on to the underly‐
213 ing command-line client. For example, with PostgreSQL you can use the
214 psql command's -c flag to execute a raw SQL query directly:
215 $ django-admin dbshell -- -c 'select current_user'
217 current_user
218 --------------
219 postgres
220 (1 row)
221 On MySQL/MariaDB, you can do this with the mysql command's -e flag:
223 $ django-admin dbshell -- -e "select user()"
225 +----------------------+
226 | user() |
227 +----------------------+
228 | djangonaut@localhost |
229 +----------------------+
230 NOTE:
232 Be aware that not all options set in the OPTIONS part of your data‐
233 base configuration in DATABASES are passed to the command-line
234 client, e.g. 'isolation_level'.
235 diffsettings
237 django-admin diffsettings
238 Displays differences between the current settings file and Django's de‐
240 fault settings (or another settings file specified by --default).
241 Settings that don't appear in the defaults are followed by "###". For
243 example, the default settings don't define ROOT_URLCONF, so ROOT_URL‐
244 CONF is followed by "###" in the output of diffsettings.
245 --all
247 Displays all settings, even if they have Django's default value. Such
249 settings are prefixed by "###".
250 --default MODULE
252 The settings module to compare the current settings against. Leave
254 empty to compare against Django's default settings.
255 --output {hash,unified}
257 Specifies the output format. Available values are hash and unified.
259 hash is the default mode that displays the output that's described
260 above. unified displays the output similar to diff -u. Default set‐
261 tings are prefixed with a minus sign, followed by the changed setting
262 prefixed with a plus sign.
263 dumpdata
265 django-admin dumpdata [app_label[.ModelName] [app_label[.ModelName]
266 ...]]
267 Outputs to standard output all data in the database associated with the
269 named application(s).
270 If no application name is provided, all installed applications will be
272 dumped.
273 The output of dumpdata can be used as input for loaddata.
275 Note that dumpdata uses the default manager on the model for selecting
277 the records to dump. If you're using a custom manager as the default
278 manager and it filters some of the available records, not all of the
279 objects will be dumped.
280 --all, -a
282 Uses Django's base manager, dumping records which might otherwise be
284 filtered or modified by a custom manager.
285 --format FORMAT
287 Specifies the serialization format of the output. Defaults to JSON.
289 Supported formats are listed in serialization-formats.
290 --indent INDENT
292 Specifies the number of indentation spaces to use in the output. De‐
294 faults to None which displays all data on single line.
295 --exclude EXCLUDE, -e EXCLUDE
297 Prevents specific applications or models (specified in the form of
299 app_label.ModelName) from being dumped. If you specify a model name,
300 then only that model will be excluded, rather than the entire applica‐
301 tion. You can also mix application names and model names.
302 If you want to exclude multiple applications, pass --exclude more than
304 once:
305 django-admin dumpdata --exclude=auth --exclude=contenttypes
307 --database DATABASE
309 Specifies the database from which data will be dumped. Defaults to de‐
311 fault.
312 --natural-foreign
314 Uses the natural_key() model method to serialize any foreign key and
316 many-to-many relationship to objects of the type that defines the
317 method. If you're dumping contrib.auth Permission objects or con‐
318 trib.contenttypes ContentType objects, you should probably use this
319 flag. See the natural keys documentation for more details on this and
320 the next option.
321 --natural-primary
323 Omits the primary key in the serialized data of this object since it
325 can be calculated during deserialization.
326 --pks PRIMARY_KEYS
328 Outputs only the objects specified by a comma separated list of primary
330 keys. This is only available when dumping one model. By default, all
331 the records of the model are output.
332 --output OUTPUT, -o OUTPUT
334 Specifies a file to write the serialized data to. By default, the data
336 goes to standard output.
337 When this option is set and --verbosity is greater than 0 (the de‐
339 fault), a progress bar is shown in the terminal.
340 Fixtures compression
342 The output file can be compressed with one of the bz2, gz, lzma, or xz
343 formats by ending the filename with the corresponding extension. For
344 example, to output the data as a compressed JSON file:
345 django-admin dumpdata -o mydata.json.gz
347 flush
349 django-admin flush
350 Removes all data from the database and re-executes any post-synchro‐
352 nization handlers. The table of which migrations have been applied is
353 not cleared.
354 If you would rather start from an empty database and re-run all migra‐
356 tions, you should drop and recreate the database and then run migrate
357 instead.
358 --noinput, --no-input
360 Suppresses all user prompts.
362 --database DATABASE
364 Specifies the database to flush. Defaults to default.
366 inspectdb
368 django-admin inspectdb [table [table ...]]
369 Introspects the database tables in the database pointed-to by the NAME
371 setting and outputs a Django model module (a models.py file) to stan‐
372 dard output.
373 You may choose what tables or views to inspect by passing their names
375 as arguments. If no arguments are provided, models are created for
376 views only if the --include-views option is used. Models for partition
377 tables are created on PostgreSQL if the --include-partitions option is
378 used.
379 Use this if you have a legacy database with which you'd like to use
381 Django. The script will inspect the database and create a model for
382 each table within it.
383 As you might expect, the created models will have an attribute for ev‐
385 ery field in the table. Note that inspectdb has a few special cases in
386 its field-name output:
387 • If inspectdb cannot map a column's type to a model field type, it'll
389 use TextField and will insert the Python comment 'This field type is
390 a guess.' next to the field in the generated model. The recognized
391 fields may depend on apps listed in INSTALLED_APPS. For example,
392 django.contrib.postgres adds recognition for several PostgreSQL-spe‐
393 cific field types.
394 • If the database column name is a Python reserved word (such as
396 'pass', 'class' or 'for'), inspectdb will append '_field' to the at‐
397 tribute name. For example, if a table has a column 'for', the gener‐
398 ated model will have a field 'for_field', with the db_column attri‐
399 bute set to 'for'. inspectdb will insert the Python comment 'Field
400 renamed because it was a Python reserved word.' next to the field.
401 This feature is meant as a shortcut, not as definitive model genera‐
403 tion. After you run it, you'll want to look over the generated models
404 yourself to make customizations. In particular, you'll need to re‐
405 arrange models' order, so that models that refer to other models are
406 ordered properly.
407 Django doesn't create database defaults when a default is specified on
409 a model field. Similarly, database defaults aren't translated to model
410 field defaults or detected in any fashion by inspectdb.
411 By default, inspectdb creates unmanaged models. That is, managed =
413 False in the model's Meta class tells Django not to manage each table's
414 creation, modification, and deletion. If you do want to allow Django to
415 manage the table's lifecycle, you'll need to change the managed option
416 to True (or remove it because True is its default value).
417 Database-specific notes
419 Oracle
420 • Models are created for materialized views if --include-views is used.
421 PostgreSQL
423 • Models are created for foreign tables.
424 • Models are created for materialized views if --include-views is used.
426 • Models are created for partition tables if --include-partitions is
428 used.
429 --database DATABASE
431 Specifies the database to introspect. Defaults to default.
433 --include-partitions
435 If this option is provided, models are also created for partitions.
437 Only support for PostgreSQL is implemented.
439 --include-views
441 If this option is provided, models are also created for database views.
443 loaddata
445 django-admin loaddata fixture [fixture ...]
446 Searches for and loads the contents of the named fixture into the data‐
448 base.
449 --database DATABASE
451 Specifies the database into which the data will be loaded. Defaults to
453 default.
454 --ignorenonexistent, -i
456 Ignores fields and models that may have been removed since the fixture
458 was originally generated.
459 --app APP_LABEL
461 Specifies a single app to look for fixtures in rather than looking in
463 all apps.
464 --format FORMAT
466 Specifies the serialization format (e.g., json or xml) for fixtures
468 read from stdin.
469 --exclude EXCLUDE, -e EXCLUDE
471 Excludes loading the fixtures from the given applications and/or models
473 (in the form of app_label or app_label.ModelName). Use the option mul‐
474 tiple times to exclude more than one app or model.
475 What's a fixture ?
477 A fixture is a collection of files that contain the serialized contents
478 of the database. Each fixture has a unique name, and the files that
479 comprise the fixture can be distributed over multiple directories, in
480 multiple applications.
481 Django will search in three locations for fixtures:
483 1. In the fixtures directory of every installed application
485 2. In any directory named in the FIXTURE_DIRS setting
487 3. In the literal path named by the fixture
489 Django will load any and all fixtures it finds in these locations that
491 match the provided fixture names.
492 If the named fixture has a file extension, only fixtures of that type
494 will be loaded. For example:
495 django-admin loaddata mydata.json
497 would only load JSON fixtures called mydata. The fixture extension must
499 correspond to the registered name of a serializer (e.g., json or xml).
500 If you omit the extensions, Django will search all available fixture
502 types for a matching fixture. For example:
503 django-admin loaddata mydata
505 would look for any fixture of any fixture type called mydata. If a fix‐
507 ture directory contained mydata.json, that fixture would be loaded as a
508 JSON fixture.
509 The fixtures that are named can include directory components. These di‐
511 rectories will be included in the search path. For example:
512 django-admin loaddata foo/bar/mydata.json
514 would search <app_label>/fixtures/foo/bar/mydata.json for each in‐
516 stalled application, <dirname>/foo/bar/mydata.json for each directory
517 in FIXTURE_DIRS, and the literal path foo/bar/mydata.json.
518 When fixture files are processed, the data is saved to the database as
520 is. Model defined save() methods are not called, and any pre_save or
521 post_save signals will be called with raw=True since the instance only
522 contains attributes that are local to the model. You may, for example,
523 want to disable handlers that access related fields that aren't present
524 during fixture loading and would otherwise raise an exception:
525 from django.db.models.signals import post_save
527 from .models import MyModel
528 def my_handler(**kwargs):
530 # disable the handler during fixture loading
531 if kwargs['raw']:
532 return
533 ...
534 post_save.connect(my_handler, sender=MyModel)
536 You could also write a decorator to encapsulate this logic:
538 from functools import wraps
540 def disable_for_loaddata(signal_handler):
542 """
543 Decorator that turns off signal handlers when loading fixture data.
544 """
545 @wraps(signal_handler)
546 def wrapper(*args, **kwargs):
547 if kwargs['raw']:
548 return
549 signal_handler(*args, **kwargs)
550 return wrapper
551 @disable_for_loaddata
553 def my_handler(**kwargs):
554 ...
555 Just be aware that this logic will disable the signals whenever fix‐
557 tures are deserialized, not just during loaddata.
558 Note that the order in which fixture files are processed is undefined.
560 However, all fixture data is installed as a single transaction, so data
561 in one fixture can reference data in another fixture. If the database
562 backend supports row-level constraints, these constraints will be
563 checked at the end of the transaction.
564 The dumpdata command can be used to generate input for loaddata.
566 Compressed fixtures
568 Fixtures may be compressed in zip, gz, bz2, lzma, or xz format. For ex‐
569 ample:
570 django-admin loaddata mydata.json
572 would look for any of mydata.json, mydata.json.zip, mydata.json.gz, my‐
574 data.json.bz2, mydata.json.lzma, or mydata.json.xz. The first file con‐
575 tained within a compressed archive is used.
576 Note that if two fixtures with the same name but different fixture type
578 are discovered (for example, if mydata.json and mydata.xml.gz were
579 found in the same fixture directory), fixture installation will be
580 aborted, and any data installed in the call to loaddata will be removed
581 from the database.
582 MySQL with MyISAM and fixtures
584 The MyISAM storage engine of MySQL doesn't support transac‐
586 tions or constraints, so if you use MyISAM, you won't get
587 validation of fixture data, or a rollback if multiple trans‐
588 action files are found.
589 Support for XZ archives (.xz) and LZMA archives (.lzma) was added.
591 Database-specific fixtures
594 If you're in a multi-database setup, you might have fixture data that
595 you want to load onto one database, but not onto another. In this situ‐
596 ation, you can add a database identifier into the names of your fix‐
597 tures.
598 For example, if your DATABASES setting has a 'master' database defined,
600 name the fixture mydata.master.json or mydata.master.json.gz and the
601 fixture will only be loaded when you specify you want to load data into
602 the master database.
603 Loading fixtures from stdin
605 You can use a dash as the fixture name to load input from sys.stdin.
606 For example:
607 django-admin loaddata --format=json -
609 When reading from stdin, the --format option is required to specify the
611 serialization format of the input (e.g., json or xml).
612 Loading from stdin is useful with standard input and output redirec‐
614 tions. For example:
615 django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -
617 makemessages
619 django-admin makemessages
620 Runs over the entire source tree of the current directory and pulls out
622 all strings marked for translation. It creates (or updates) a message
623 file in the conf/locale (in the Django tree) or locale (for project and
624 application) directory. After making changes to the messages files you
625 need to compile them with compilemessages for use with the builtin get‐
626 text support. See the i18n documentation for details.
627 This command doesn't require configured settings. However, when set‐
629 tings aren't configured, the command can't ignore the MEDIA_ROOT and
630 STATIC_ROOT directories or include LOCALE_PATHS.
631 --all, -a
633 Updates the message files for all available languages.
635 --extension EXTENSIONS, -e EXTENSIONS
637 Specifies a list of file extensions to examine (default: html, txt, py
639 or js if --domain is js).
640 Example usage:
642 django-admin makemessages --locale=de --extension xhtml
644 Separate multiple extensions with commas or use -e or --extension mul‐
646 tiple times:
647 django-admin makemessages --locale=de --extension=html,txt --extension xml
649 --locale LOCALE, -l LOCALE
651 Specifies the locale(s) to process.
653 --exclude EXCLUDE, -x EXCLUDE
655 Specifies the locale(s) to exclude from processing. If not provided, no
657 locales are excluded.
658 Example usage:
660 django-admin makemessages --locale=pt_BR
662 django-admin makemessages --locale=pt_BR --locale=fr
663 django-admin makemessages -l pt_BR
664 django-admin makemessages -l pt_BR -l fr
665 django-admin makemessages --exclude=pt_BR
666 django-admin makemessages --exclude=pt_BR --exclude=fr
667 django-admin makemessages -x pt_BR
668 django-admin makemessages -x pt_BR -x fr
669 --domain DOMAIN, -d DOMAIN
671 Specifies the domain of the messages files. Supported options are:
673 • django for all *.py, *.html and *.txt files (default)
675 • djangojs for *.js files
677 --symlinks, -s
679 Follows symlinks to directories when looking for new translation
681 strings.
682 Example usage:
684 django-admin makemessages --locale=de --symlinks
686 --ignore PATTERN, -i PATTERN
688 Ignores files or directories matching the given glob-style pattern. Use
690 multiple times to ignore more.
691 These patterns are used by default: 'CVS', '.*', '*~', '*.pyc'.
693 Example usage:
695 django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html
697 --no-default-ignore
699 Disables the default values of --ignore.
701 --no-wrap
703 Disables breaking long message lines into several lines in language
705 files.
706 --no-location
708 Suppresses writing '#: filename:line’ comment lines in language files.
710 Using this option makes it harder for technically skilled translators
711 to understand each message's context.
712 --add-location [{full,file,never}]
714 Controls #: filename:line comment lines in language files. If the op‐
716 tion is:
717 • full (the default if not given): the lines include both file name and
719 line number.
720 • file: the line number is omitted.
722 • never: the lines are suppressed (same as --no-location).
724 Requires gettext 0.19 or newer.
726 --keep-pot
728 Prevents deleting the temporary .pot files generated before creating
730 the .po file. This is useful for debugging errors which may prevent the
731 final language files from being created.
732 SEE ALSO:
734 See customizing-makemessages for instructions on how to customize
735 the keywords that makemessages passes to xgettext.
736 makemigrations
738 django-admin makemigrations [app_label [app_label ...]]
739 Creates new migrations based on the changes detected to your models.
741 Migrations, their relationship with apps and more are covered in depth
742 in the migrations documentation.
743 Providing one or more app names as arguments will limit the migrations
745 created to the app(s) specified and any dependencies needed (the table
746 at the other end of a ForeignKey, for example).
747 To add migrations to an app that doesn't have a migrations directory,
749 run makemigrations with the app's app_label.
750 --noinput, --no-input
752 Suppresses all user prompts. If a suppressed prompt cannot be resolved
754 automatically, the command will exit with error code 3.
755 --empty
757 Outputs an empty migration for the specified apps, for manual editing.
759 This is for advanced users and should not be used unless you are famil‐
760 iar with the migration format, migration operations, and the dependen‐
761 cies between your migrations.
762 --dry-run
764 Shows what migrations would be made without actually writing any migra‐
766 tions files to disk. Using this option along with --verbosity 3 will
767 also show the complete migrations files that would be written.
768 --merge
770 Enables fixing of migration conflicts.
772 --name NAME, -n NAME
774 Allows naming the generated migration(s) instead of using a generated
776 name. The name must be a valid Python identifier.
777 --no-header
779 Generate migration files without Django version and timestamp header.
781 --check
783 Makes makemigrations exit with a non-zero status when model changes
785 without migrations are detected.
786 Support for calling makemigrations without an active database connec‐
788 tion was added. In that case, check for a consistent migration history
789 is skipped.
790 migrate
793 django-admin migrate [app_label] [migration_name]
794 Synchronizes the database state with the current set of models and mi‐
796 grations. Migrations, their relationship with apps and more are cov‐
797 ered in depth in the migrations documentation.
798 The behavior of this command changes depending on the arguments pro‐
800 vided:
801 • No arguments: All apps have all of their migrations run.
803 • <app_label>: The specified app has its migrations run, up to the most
805 recent migration. This may involve running other apps' migrations
806 too, due to dependencies.
807 • <app_label> <migrationname>: Brings the database schema to a state
809 where the named migration is applied, but no later migrations in the
810 same app are applied. This may involve unapplying migrations if you
811 have previously migrated past the named migration. You can use a pre‐
812 fix of the migration name, e.g. 0001, as long as it's unique for the
813 given app name. Use the name zero to migrate all the way back i.e. to
814 revert all applied migrations for an app.
815 WARNING:
817 When unapplying migrations, all dependent migrations will also be
818 unapplied, regardless of <app_label>. You can use --plan to check
819 which migrations will be unapplied.
820 --database DATABASE
822 Specifies the database to migrate. Defaults to default.
824 --fake
826 Marks the migrations up to the target one (following the rules above)
828 as applied, but without actually running the SQL to change your data‐
829 base schema.
830 This is intended for advanced users to manipulate the current migration
832 state directly if they're manually applying changes; be warned that us‐
833 ing --fake runs the risk of putting the migration state table into a
834 state where manual recovery will be needed to make migrations run cor‐
835 rectly.
836 --fake-initial
838 Allows Django to skip an app's initial migration if all database tables
840 with the names of all models created by all CreateModel operations in
841 that migration already exist. This option is intended for use when
842 first running migrations against a database that preexisted the use of
843 migrations. This option does not, however, check for matching database
844 schema beyond matching table names and so is only safe to use if you
845 are confident that your existing schema matches what is recorded in
846 your initial migration.
847 --plan
849 Shows the migration operations that will be performed for the given mi‐
851 grate command.
852 --run-syncdb
854 Allows creating tables for apps without migrations. While this isn't
856 recommended, the migrations framework is sometimes too slow on large
857 projects with hundreds of models.
858 --noinput, --no-input
860 Suppresses all user prompts. An example prompt is asking about removing
862 stale content types.
863 --check
865 Makes migrate exit with a non-zero status when unapplied migrations are
869 detected.
870 runserver
872 django-admin runserver [addrport]
873 Starts a lightweight development Web server on the local machine. By
875 default, the server runs on port 8000 on the IP address 127.0.0.1. You
876 can pass in an IP address and port number explicitly.
877 If you run this script as a user with normal privileges (recommended),
879 you might not have access to start a port on a low port number. Low
880 port numbers are reserved for the superuser (root).
881 This server uses the WSGI application object specified by the WSGI_AP‐
883 PLICATION setting.
884 DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through
886 security audits or performance tests. (And that's how it's gonna stay.
887 We're in the business of making Web frameworks, not Web servers, so im‐
888 proving this server to be able to handle a production environment is
889 outside the scope of Django.)
890 The development server automatically reloads Python code for each re‐
892 quest, as needed. You don't need to restart the server for code changes
893 to take effect. However, some actions like adding files don't trigger
894 a restart, so you'll have to restart the server in these cases.
895 If you're using Linux or MacOS and install both pywatchman and the
897 Watchman service, kernel signals will be used to autoreload the server
898 (rather than polling file modification timestamps each second). This
899 offers better performance on large projects, reduced response time af‐
900 ter code changes, more robust change detection, and a reduction in
901 power usage. Django supports pywatchman 1.2.0 and higher.
902 Large directories with many files may cause performance issues
904 When using Watchman with a project that includes large
906 non-Python directories like node_modules, it's advisable to
907 ignore this directory for optimal performance. See the
908 watchman documentation for information on how to do this.
909 Watchman timeout
911 DJANGO_WATCHMAN_TIMEOUT
913 The default timeout of Watchman client is 5 seconds. You can change
915 it by setting the DJANGO_WATCHMAN_TIMEOUT environment variable.
916 When you start the server, and each time you change Python code while
918 the server is running, the system check framework will check your en‐
919 tire Django project for some common errors (see the check command). If
920 any errors are found, they will be printed to standard output.
921 You can run as many concurrent servers as you want, as long as they're
923 on separate ports by executing django-admin runserver more than once.
924 Note that the default IP address, 127.0.0.1, is not accessible from
926 other machines on your network. To make your development server view‐
927 able to other machines on the network, use its own IP address (e.g.
928 192.168.2.1) or 0.0.0.0 or :: (with IPv6 enabled).
929 You can provide an IPv6 address surrounded by brackets (e.g.
931 [200a::1]:8000). This will automatically enable IPv6 support.
932 A hostname containing ASCII-only characters can also be used.
934 If the staticfiles contrib app is enabled (default in new projects) the
936 runserver command will be overridden with its own runserver command.
937 Logging of each request and response of the server is sent to the
939 django-server-logger logger.
940 --noreload
942 Disables the auto-reloader. This means any Python code changes you make
944 while the server is running will not take effect if the particular
945 Python modules have already been loaded into memory.
946 --nothreading
948 Disables use of threading in the development server. The server is mul‐
950 tithreaded by default.
951 --ipv6, -6
953 Uses IPv6 for the development server. This changes the default IP ad‐
955 dress from 127.0.0.1 to ::1.
956 Examples of using different ports and addresses
958 Port 8000 on IP address 127.0.0.1:
959 django-admin runserver
961 Port 8000 on IP address 1.2.3.4:
963 django-admin runserver 1.2.3.4:8000
965 Port 7000 on IP address 127.0.0.1:
967 django-admin runserver 7000
969 Port 7000 on IP address 1.2.3.4:
971 django-admin runserver 1.2.3.4:7000
973 Port 8000 on IPv6 address ::1:
975 django-admin runserver -6
977 Port 7000 on IPv6 address ::1:
979 django-admin runserver -6 7000
981 Port 7000 on IPv6 address 2001:0db8:1234:5678::9:
983 django-admin runserver [2001:0db8:1234:5678::9]:7000
985 Port 8000 on IPv4 address of host localhost:
987 django-admin runserver localhost:8000
989 Port 8000 on IPv6 address of host localhost:
991 django-admin runserver -6 localhost:8000
993 Serving static files with the development server
995 By default, the development server doesn't serve any static files for
996 your site (such as CSS files, images, things under MEDIA_URL and so
997 forth). If you want to configure Django to serve static media, read
998 /howto/static-files/index.
999 sendtestemail
1001 django-admin sendtestemail [email [email ...]]
1002 Sends a test email (to confirm email sending through Django is working)
1004 to the recipient(s) specified. For example:
1005 django-admin sendtestemail foo@example.com bar@example.com
1007 There are a couple of options, and you may use any combination of them
1009 together:
1010 --managers
1012 Mails the email addresses specified in MANAGERS using mail_managers().
1014 --admins
1016 Mails the email addresses specified in ADMINS using mail_admins().
1018 shell
1020 django-admin shell
1021 Starts the Python interactive interpreter.
1023 --interface {ipython,bpython,python}, -i {ipython,bpython,python}
1025 Specifies the shell to use. By default, Django will use IPython or
1027 bpython if either is installed. If both are installed, specify which
1028 one you want like so:
1029 IPython:
1031 django-admin shell -i ipython
1033 bpython:
1035 django-admin shell -i bpython
1037 If you have a "rich" shell installed but want to force use of the
1039 "plain" Python interpreter, use python as the interface name, like so:
1040 django-admin shell -i python
1042 --nostartup
1044 Disables reading the startup script for the "plain" Python interpreter.
1046 By default, the script pointed to by the PYTHONSTARTUP environment
1047 variable or the ~/.pythonrc.py script is read.
1048 --command COMMAND, -c COMMAND
1050 Lets you pass a command as a string to execute it as Django, like so:
1052 django-admin shell --command="import django; print(django.__version__)"
1054 You can also pass code in on standard input to execute it. For example:
1056 $ django-admin shell <<EOF
1058 > import django
1059 > print(django.__version__)
1060 > EOF
1061 On Windows, the REPL is output due to implementation limits of
1063 select.select() on that platform.
1064 showmigrations
1066 django-admin showmigrations [app_label [app_label ...]]
1067 Shows all migrations in a project. You can choose from one of two for‐
1069 mats:
1070 --list, -l
1072 Lists all of the apps Django knows about, the migrations available for
1074 each app, and whether or not each migration is applied (marked by an
1075 [X] next to the migration name). For a --verbosity of 2 and above, the
1076 applied datetimes are also shown.
1077 Apps without migrations are also listed, but have (no migrations)
1079 printed under them.
1080 This is the default output format.
1082 --plan, -p
1084 Shows the migration plan Django will follow to apply migrations. Like
1086 --list, applied migrations are marked by an [X]. For a --verbosity of 2
1087 and above, all dependencies of a migration will also be shown.
1088 app_labels arguments limit the output, however, dependencies of pro‐
1090 vided apps may also be included.
1091 --database DATABASE
1093 Specifies the database to examine. Defaults to default.
1095 sqlflush
1097 django-admin sqlflush
1098 Prints the SQL statements that would be executed for the flush command.
1100 --database DATABASE
1102 Specifies the database for which to print the SQL. Defaults to default.
1104 sqlmigrate
1106 django-admin sqlmigrate app_label migration_name
1107 Prints the SQL for the named migration. This requires an active data‐
1109 base connection, which it will use to resolve constraint names; this
1110 means you must generate the SQL against a copy of the database you wish
1111 to later apply it on.
1112 Note that sqlmigrate doesn't colorize its output.
1114 --backwards
1116 Generates the SQL for unapplying the migration. By default, the SQL
1118 created is for running the migration in the forwards direction.
1119 --database DATABASE
1121 Specifies the database for which to generate the SQL. Defaults to de‐
1123 fault.
1124 sqlsequencereset
1126 django-admin sqlsequencereset app_label [app_label ...]
1127 Prints the SQL statements for resetting sequences for the given app
1129 name(s).
1130 Sequences are indexes used by some database engines to track the next
1132 available number for automatically incremented fields.
1133 Use this command to generate SQL which will fix cases where a sequence
1135 is out of sync with its automatically incremented field data.
1136 --database DATABASE
1138 Specifies the database for which to print the SQL. Defaults to default.
1140 squashmigrations
1142 django-admin squashmigrations app_label [start_migration_name] migra‐
1143 tion_name
1144 Squashes the migrations for app_label up to and including migra‐
1146 tion_name down into fewer migrations, if possible. The resulting
1147 squashed migrations can live alongside the unsquashed ones safely. For
1148 more information, please read migration-squashing.
1149 When start_migration_name is given, Django will only include migrations
1151 starting from and including this migration. This helps to mitigate the
1152 squashing limitation of RunPython and django.db.migrations.opera‐
1153 tions.RunSQL migration operations.
1154 --no-optimize
1156 Disables the optimizer when generating a squashed migration. By de‐
1158 fault, Django will try to optimize the operations in your migrations to
1159 reduce the size of the resulting file. Use this option if this process
1160 is failing or creating incorrect migrations, though please also file a
1161 Django bug report about the behavior, as optimization is meant to be
1162 safe.
1163 --noinput, --no-input
1165 Suppresses all user prompts.
1167 --squashed-name SQUASHED_NAME
1169 Sets the name of the squashed migration. When omitted, the name is
1171 based on the first and last migration, with _squashed_ in between.
1172 --no-header
1174 Generate squashed migration file without Django version and timestamp
1176 header.
1177 startapp
1179 django-admin startapp name [directory]
1180 Creates a Django app directory structure for the given app name in the
1182 current directory or the given destination.
1183 By default, the new directory contains a models.py file and other app
1185 template files. If only the app name is given, the app directory will
1186 be created in the current working directory.
1187 If the optional destination is provided, Django will use that existing
1189 directory rather than creating a new one. You can use '.' to denote the
1190 current working directory.
1191 For example:
1193 django-admin startapp myapp /Users/jezdez/Code/myapp
1195 --template TEMPLATE
1197 Provides the path to a directory with a custom app template file, or a
1199 path to an uncompressed archive (.tar) or a compressed archive
1200 (.tar.gz, .tar.bz2, .tar.xz, .tar.lzma, .tgz, .tbz2, .txz, .tlz, .zip)
1201 containing the app template files.
1202 For example, this would look for an app template in the given directory
1204 when creating the myapp app:
1205 django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp
1207 Django will also accept URLs (http, https, ftp) to compressed archives
1209 with the app template files, downloading and extracting them on the
1210 fly.
1211 For example, taking advantage of GitHub's feature to expose reposito‐
1213 ries as zip files, you can use a URL like:
1214 django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip myapp
1216 --extension EXTENSIONS, -e EXTENSIONS
1218 Specifies which file extensions in the app template should be rendered
1220 with the template engine. Defaults to py.
1221 --name FILES, -n FILES
1223 Specifies which files in the app template (in addition to those match‐
1225 ing --extension) should be rendered with the template engine. Defaults
1226 to an empty list.
1227 The template context used for all matching files is:
1229 • Any option passed to the startapp command (among the command's sup‐
1231 ported options)
1232 • app_name -- the app name as passed to the command
1234 • app_directory -- the full path of the newly created app
1236 • camel_case_app_name -- the app name in camel case format
1238 • docs_version -- the version of the documentation: 'dev' or '1.x'
1240 • django_version -- the version of Django, e.g. '2.0.3'
1242 WARNING:
1244 When the app template files are rendered with the Django template
1245 engine (by default all *.py files), Django will also replace all
1246 stray template variables contained. For example, if one of the
1247 Python files contains a docstring explaining a particular feature
1248 related to template rendering, it might result in an incorrect exam‐
1249 ple.
1250 To work around this problem, you can use the templatetag template
1252 tag to "escape" the various parts of the template syntax.
1253 In addition, to allow Python template files that contain Django tem‐
1255 plate language syntax while also preventing packaging systems from
1256 trying to byte-compile invalid *.py files, template files ending
1257 with .py-tpl will be renamed to .py.
1258 startproject
1260 django-admin startproject name [directory]
1261 Creates a Django project directory structure for the given project name
1263 in the current directory or the given destination.
1264 By default, the new directory contains manage.py and a project package
1266 (containing a settings.py and other files).
1267 If only the project name is given, both the project directory and
1269 project package will be named <projectname> and the project directory
1270 will be created in the current working directory.
1271 If the optional destination is provided, Django will use that existing
1273 directory as the project directory, and create manage.py and the
1274 project package within it. Use '.' to denote the current working direc‐
1275 tory.
1276 For example:
1278 django-admin startproject myproject /Users/jezdez/Code/myproject_repo
1280 --template TEMPLATE
1282 Specifies a directory, file path, or URL of a custom project template.
1284 See the startapp --template documentation for examples and usage.
1285 --extension EXTENSIONS, -e EXTENSIONS
1287 Specifies which file extensions in the project template should be ren‐
1289 dered with the template engine. Defaults to py.
1290 --name FILES, -n FILES
1292 Specifies which files in the project template (in addition to those
1294 matching --extension) should be rendered with the template engine. De‐
1295 faults to an empty list.
1296 The template context used is:
1298 • Any option passed to the startproject command (among the command's
1300 supported options)
1301 • project_name -- the project name as passed to the command
1303 • project_directory -- the full path of the newly created project
1305 • secret_key -- a random key for the SECRET_KEY setting
1307 • docs_version -- the version of the documentation: 'dev' or '1.x'
1309 • django_version -- the version of Django, e.g. '2.0.3'
1311 Please also see the rendering warning as mentioned for startapp.
1313 test
1315 django-admin test [test_label [test_label ...]]
1316 Runs tests for all installed apps. See /topics/testing/index for more
1318 information.
1319 --failfast
1321 Stops running tests and reports the failure immediately after a test
1323 fails.
1324 --testrunner TESTRUNNER
1326 Controls the test runner class that is used to execute tests. This
1328 value overrides the value provided by the TEST_RUNNER setting.
1329 --noinput, --no-input
1331 Suppresses all user prompts. A typical prompt is a warning about delet‐
1333 ing an existing test database.
1334 Test runner options
1336 The test command receives options on behalf of the specified
1337 --testrunner. These are the options of the default test runner: Discov‐
1338 erRunner.
1339 --keepdb
1341 Preserves the test database between test runs. This has the advantage
1343 of skipping both the create and destroy actions which can greatly de‐
1344 crease the time to run tests, especially those in a large test suite.
1345 If the test database does not exist, it will be created on the first
1346 run and then preserved for each subsequent run. Unless the MIGRATE test
1347 setting is False, any unapplied migrations will also be applied to the
1348 test database before running the test suite.
1349 --reverse, -r
1351 Sorts test cases in the opposite execution order. This may help in de‐
1353 bugging the side effects of tests that aren't properly isolated. Group‐
1354 ing by test class is preserved when using this option.
1355 --debug-mode
1357 Sets the DEBUG setting to True prior to running tests. This may help
1359 troubleshoot test failures.
1360 --debug-sql, -d
1362 Enables SQL logging for failing tests. If --verbosity is 2, then
1364 queries in passing tests are also output.
1365 --parallel [N]
1367 DJANGO_TEST_PROCESSES
1369 Runs tests in separate parallel processes. Since modern processors have
1371 multiple cores, this allows running tests significantly faster.
1372 By default --parallel runs one process per core according to
1374 multiprocessing.cpu_count(). You can adjust the number of processes ei‐
1375 ther by providing it as the option's value, e.g. --parallel=4, or by
1376 setting the DJANGO_TEST_PROCESSES environment variable.
1377 Django distributes test cases — unittest.TestCase subclasses — to sub‐
1379 processes. If there are fewer test cases than configured processes,
1380 Django will reduce the number of processes accordingly.
1381 Each process gets its own database. You must ensure that different test
1383 cases don't access the same resources. For instance, test cases that
1384 touch the filesystem should create a temporary directory for their own
1385 use.
1386 NOTE:
1388 If you have test classes that cannot be run in parallel, you can use
1389 SerializeMixin to run them sequentially. See Enforce running test
1390 classes sequentially.
1391 This option requires the third-party tblib package to display trace‐
1393 backs correctly:
1394 $ python -m pip install tblib
1396 This feature isn't available on Windows. It doesn't work with the Ora‐
1398 cle database backend either.
1399 If you want to use pdb while debugging tests, you must disable parallel
1401 execution (--parallel=1). You'll see something like bdb.BdbQuit if you
1402 don't.
1403 WARNING:
1405 When test parallelization is enabled and a test fails, Django may be
1406 unable to display the exception traceback. This can make debugging
1407 difficult. If you encounter this problem, run the affected test
1408 without parallelization to see the traceback of the failure.
1409 This is a known limitation. It arises from the need to serialize ob‐
1411 jects in order to exchange them between processes. See What can be
1412 pickled and unpickled? for details.
1413 --tag TAGS
1415 Runs only tests marked with the specified tags. May be specified mul‐
1417 tiple times and combined with test --exclude-tag.
1418 --exclude-tag EXCLUDE_TAGS
1420 Excludes tests marked with the specified tags. May be specified multi‐
1422 ple times and combined with test --tag.
1423 -k TEST_NAME_PATTERNS
1425 Runs test methods and classes matching test name patterns, in the same
1427 way as unittest's -k option. Can be specified multiple times.
1428 Python 3.7 and later
1430 This feature is only available for Python 3.7 and later.
1432 --pdb
1434 Spawns a pdb debugger at each test error or failure. If you have it in‐
1436 stalled, ipdb is used instead.
1437 --buffer, -b
1439 Discards output (stdout and stderr) for passing tests, in the same way
1443 as unittest's --buffer option.
1444 --no-faulthandler
1446 Django automatically calls faulthandler.enable() when starting the
1450 tests, which allows it to print a traceback if the interpreter crashes.
1451 Pass --no-faulthandler to disable this behavior.
1452 --timing
1454 Outputs timings, including database setup and total run time.
1458 testserver
1460 django-admin testserver [fixture [fixture ...]]
1461 Runs a Django development server (as in runserver) using data from the
1463 given fixture(s).
1464 For example, this command:
1466 django-admin testserver mydata.json
1468 ...would perform the following steps:
1470 1. Create a test database, as described in the-test-database.
1472 2. Populate the test database with fixture data from the given fix‐
1474 tures. (For more on fixtures, see the documentation for loaddata
1475 above.)
1476 3. Runs the Django development server (as in runserver), pointed at
1478 this newly created test database instead of your production data‐
1479 base.
1480 This is useful in a number of ways:
1482 • When you're writing unit tests of how your views act with certain
1484 fixture data, you can use testserver to interact with the views in a
1485 Web browser, manually.
1486 • Let's say you're developing your Django application and have a "pris‐
1488 tine" copy of a database that you'd like to interact with. You can
1489 dump your database to a fixture (using the dumpdata command, ex‐
1490 plained above), then use testserver to run your Web application with
1491 that data. With this arrangement, you have the flexibility of mess‐
1492 ing up your data in any way, knowing that whatever data changes
1493 you're making are only being made to a test database.
1494 Note that this server does not automatically detect changes to your
1496 Python source code (as runserver does). It does, however, detect
1497 changes to templates.
1498 --addrport ADDRPORT
1500 Specifies a different port, or IP address and port, from the default of
1502 127.0.0.1:8000. This value follows exactly the same format and serves
1503 exactly the same function as the argument to the runserver command.
1504 Examples:
1506 To run the test server on port 7000 with fixture1 and fixture2:
1508 django-admin testserver --addrport 7000 fixture1 fixture2
1510 django-admin testserver fixture1 fixture2 --addrport 7000
1511 (The above statements are equivalent. We include both of them to demon‐
1513 strate that it doesn't matter whether the options come before or after
1514 the fixture arguments.)
1515 To run on 1.2.3.4:7000 with a test fixture:
1517 django-admin testserver --addrport 1.2.3.4:7000 test
1519 --noinput, --no-input
1521 Suppresses all user prompts. A typical prompt is a warning about delet‐
1523 ing an existing test database.
1524
1526 Some commands are only available when the django.contrib application
1527 that implements them has been enabled. This section describes them
1528 grouped by their application.
1529 django.contrib.auth
1531 changepassword
1532 django-admin changepassword [<username>]
1533 This command is only available if Django's authentication system
1535 (django.contrib.auth) is installed.
1536 Allows changing a user's password. It prompts you to enter a new pass‐
1538 word twice for the given user. If the entries are identical, this imme‐
1539 diately becomes the new password. If you do not supply a user, the com‐
1540 mand will attempt to change the password whose username matches the
1541 current user.
1542 --database DATABASE
1544 Specifies the database to query for the user. Defaults to default.
1546 Example usage:
1548 django-admin changepassword ringo
1550 createsuperuser
1552 django-admin createsuperuser
1553 DJANGO_SUPERUSER_PASSWORD
1555 This command is only available if Django's authentication system
1557 (django.contrib.auth) is installed.
1558 Creates a superuser account (a user who has all permissions). This is
1560 useful if you need to create an initial superuser account or if you
1561 need to programmatically generate superuser accounts for your site(s).
1562 When run interactively, this command will prompt for a password for the
1564 new superuser account. When run non-interactively, you can provide a
1565 password by setting the DJANGO_SUPERUSER_PASSWORD environment variable.
1566 Otherwise, no password will be set, and the superuser account will not
1567 be able to log in until a password has been manually set for it.
1568 In non-interactive mode, the USERNAME_FIELD and required fields (listed
1570 in REQUIRED_FIELDS) fall back to DJANGO_SUPERUSER_<upper‐
1571 case_field_name> environment variables, unless they are overridden by a
1572 command line argument. For example, to provide an email field, you can
1573 use DJANGO_SUPERUSER_EMAIL environment variable.
1574 --noinput, --no-input
1576 Suppresses all user prompts. If a suppressed prompt cannot be resolved
1578 automatically, the command will exit with error code 1.
1579 --username USERNAME
1581 --email EMAIL
1583 The username and email address for the new account can be supplied by
1585 using the --username and --email arguments on the command line. If ei‐
1586 ther of those is not supplied, createsuperuser will prompt for it when
1587 running interactively.
1588 --database DATABASE
1590 Specifies the database into which the superuser object will be saved.
1592 You can subclass the management command and override get_input_data()
1594 if you want to customize data input and validation. Consult the source
1595 code for details on the existing implementation and the method's param‐
1596 eters. For example, it could be useful if you have a ForeignKey in RE‐
1597 QUIRED_FIELDS and want to allow creating an instance instead of enter‐
1598 ing the primary key of an existing instance.
1599 django.contrib.contenttypes
1601 remove_stale_contenttypes
1602 django-admin remove_stale_contenttypes
1603 This command is only available if Django's contenttypes app
1605 (django.contrib.contenttypes) is installed.
1606 Deletes stale content types (from deleted models) in your database. Any
1608 objects that depend on the deleted content types will also be deleted.
1609 A list of deleted objects will be displayed before you confirm it's
1610 okay to proceed with the deletion.
1611 --database DATABASE
1613 Specifies the database to use. Defaults to default.
1615 --include-stale-apps
1617 Deletes stale content types including ones from previously installed
1621 apps that have been removed from INSTALLED_APPS. Defaults to False.
1622 django.contrib.gis
1624 ogrinspect
1625 This command is only available if GeoDjango (django.contrib.gis) is in‐
1626 stalled.
1627 Please refer to its description in the GeoDjango documentation.
1629 django.contrib.sessions
1631 clearsessions
1632 django-admin clearsessions
1633 Can be run as a cron job or directly to clean out expired sessions.
1635 django.contrib.sitemaps
1637 ping_google
1638 This command is only available if the Sitemaps framework (django.con‐
1639 trib.sitemaps) is installed.
1640 Please refer to its description in the Sitemaps documentation.
1642 django.contrib.staticfiles
1644 collectstatic
1645 This command is only available if the static files application
1646 (django.contrib.staticfiles) is installed.
1647 Please refer to its description in the staticfiles documentation.
1649 findstatic
1651 This command is only available if the static files application
1652 (django.contrib.staticfiles) is installed.
1653 Please refer to its description in the staticfiles documentation.
1655
1657 Although some commands may allow their own custom options, every com‐
1658 mand allows for the following options:
1659 --pythonpath PYTHONPATH
1661 Adds the given filesystem path to the Python import search path. If
1663 this isn't provided, django-admin will use the PYTHONPATH environment
1664 variable.
1665 This option is unnecessary in manage.py, because it takes care of set‐
1667 ting the Python path for you.
1668 Example usage:
1670 django-admin migrate --pythonpath='/home/djangoprojects/myproject'
1672 --settings SETTINGS
1674 Specifies the settings module to use. The settings module should be in
1676 Python package syntax, e.g. mysite.settings. If this isn't provided,
1677 django-admin will use the DJANGO_SETTINGS_MODULE environment variable.
1678 This option is unnecessary in manage.py, because it uses settings.py
1680 from the current project by default.
1681 Example usage:
1683 django-admin migrate --settings=mysite.settings
1685 --traceback
1687 Displays a full stack trace when a CommandError is raised. By default,
1689 django-admin will show an error message when a CommandError occurs and
1690 a full stack trace for any other exception.
1691 Example usage:
1693 django-admin migrate --traceback
1695 --verbosity {0,1,2,3}, -v {0,1,2,3}
1697 Specifies the amount of notification and debug information that a com‐
1699 mand should print to the console.
1700 • 0 means no output.
1702 • 1 means normal output (default).
1704 • 2 means verbose output.
1706 • 3 means very verbose output.
1708 Example usage:
1710 django-admin migrate --verbosity 2
1712 --no-color
1714 Disables colorized command output. Some commands format their output
1716 to be colorized. For example, errors will be printed to the console in
1717 red and SQL statements will be syntax highlighted.
1718 Example usage:
1720 django-admin runserver --no-color
1722 --force-color
1724 Forces colorization of the command output if it would otherwise be dis‐
1726 abled as discussed in Syntax coloring. For example, you may want to
1727 pipe colored output to another command.
1728 --skip-checks
1730 Skips running system checks prior to running the command. This option
1732 is only available if the requires_system_checks command attribute is
1733 not an empty list or tuple.
1734 Example usage:
1736 django-admin migrate --skip-checks
1738
1740 Syntax coloring
1741 DJANGO_COLORS
1742 The django-admin / manage.py commands will use pretty color-coded out‐
1744 put if your terminal supports ANSI-colored output. It won't use the
1745 color codes if you're piping the command's output to another program
1746 unless the --force-color option is used.
1747 Windows support
1749 On Windows 10, the Windows Terminal application, VS Code, and Power‐
1750 Shell (where virtual terminal processing is enabled) allow colored out‐
1751 put, and are supported by default.
1752 Under Windows, the legacy cmd.exe native console doesn't support ANSI
1754 escape sequences so by default there is no color output. In this case
1755 either of two third-party libraries are needed:
1756 • Install colorama, a Python package that translates ANSI color codes
1758 into Windows API calls. Django commands will detect its presence and
1759 will make use of its services to color output just like on Unix-based
1760 platforms. colorama can be installed via pip:
1761 ...\> py -m pip install colorama
1763 • Install ANSICON, a third-party tool that allows cmd.exe to process
1765 ANSI color codes. Django commands will detect its presence and will
1766 make use of its services to color output just like on Unix-based
1767 platforms.
1768 Other modern terminal environments on Windows, that support terminal
1770 colors, but which are not automatically detected as supported by
1771 Django, may "fake" the installation of ANSICON by setting the appropri‐
1772 ate environmental variable, ANSICON="on".
1773 Updated support for syntax coloring on Windows.
1775 Custom colors
1778 The colors used for syntax highlighting can be customized. Django ships
1779 with three color palettes:
1780 • dark, suited to terminals that show white text on a black background.
1782 This is the default palette.
1783 • light, suited to terminals that show black text on a white back‐
1785 ground.
1786 • nocolor, which disables syntax highlighting.
1788 You select a palette by setting a DJANGO_COLORS environment variable to
1790 specify the palette you want to use. For example, to specify the light
1791 palette under a Unix or OS/X BASH shell, you would run the following at
1792 a command prompt:
1793 export DJANGO_COLORS="light"
1795 You can also customize the colors that are used. Django specifies a
1797 number of roles in which color is used:
1798 • error - A major error.
1800 • notice - A minor error.
1802 • success - A success.
1804 • warning - A warning.
1806 • sql_field - The name of a model field in SQL.
1808 • sql_coltype - The type of a model field in SQL.
1810 • sql_keyword - An SQL keyword.
1812 • sql_table - The name of a model in SQL.
1814 • http_info - A 1XX HTTP Informational server response.
1816 • http_success - A 2XX HTTP Success server response.
1818 • http_not_modified - A 304 HTTP Not Modified server response.
1820 • http_redirect - A 3XX HTTP Redirect server response other than 304.
1822 • http_not_found - A 404 HTTP Not Found server response.
1824 • http_bad_request - A 4XX HTTP Bad Request server response other than
1826 404.
1827 • http_server_error - A 5XX HTTP Server Error response.
1829 • migrate_heading - A heading in a migrations management command.
1831 • migrate_label - A migration name.
1833 Each of these roles can be assigned a specific foreground and back‐
1835 ground color, from the following list:
1836 • black
1838 • red
1840 • green
1842 • yellow
1844 • blue
1846 • magenta
1848 • cyan
1850 • white
1852 Each of these colors can then be modified by using the following dis‐
1854 play options:
1855 • bold
1857 • underscore
1859 • blink
1861 • reverse
1863 • conceal
1865 A color specification follows one of the following patterns:
1867 • role=fg
1869 • role=fg/bg
1871 • role=fg,option,option
1873 • role=fg/bg,option,option
1875 where role is the name of a valid color role, fg is the foreground
1877 color, bg is the background color and each option is one of the color
1878 modifying options. Multiple color specifications are then separated by
1879 a semicolon. For example:
1880 export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
1882 would specify that errors be displayed using blinking yellow on blue,
1884 and notices displayed using magenta. All other color roles would be
1885 left uncolored.
1886 Colors can also be specified by extending a base palette. If you put a
1888 palette name in a color specification, all the colors implied by that
1889 palette will be loaded. So:
1890 export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
1892 would specify the use of all the colors in the light color palette, ex‐
1894 cept for the colors for errors and notices which would be overridden as
1895 specified.
1896 Bash completion
1898 If you use the Bash shell, consider installing the Django bash comple‐
1899 tion script, which lives in extras/django_bash_completion in the Django
1900 source distribution. It enables tab-completion of django-admin and man‐
1901 age.py commands, so you can, for instance...
1902 • Type django-admin.
1904 • Press [TAB] to see all available options.
1906 • Type sql, then [TAB], to see all available options whose names start
1908 with sql.
1909 See /howto/custom-management-commands for how to add customized ac‐
1911 tions.
1912 django.core.management.call_command(name, *args, **options)
1914 To call a management command from code use call_command.
1916 name the name of the command to call or a command object. Passing the
1918 name is preferred unless the object is required for testing.
1919 *args a list of arguments accepted by the command. Arguments are
1921 passed to the argument parser, so you can use the same style as
1922 you would on the command line. For example, call_com‐
1923 mand('flush', '--verbosity=0').
1924 **options
1926 named options accepted on the command-line. Options are passed
1927 to the command without triggering the argument parser, which
1928 means you'll need to pass the correct type. For example,
1929 call_command('flush', verbosity=0) (zero must be an integer
1930 rather than a string).
1931 Examples:
1933 from django.core import management
1935 from django.core.management.commands import loaddata
1936 management.call_command('flush', verbosity=0, interactive=False)
1938 management.call_command('loaddata', 'test_data', verbosity=0)
1939 management.call_command(loaddata.Command(), 'test_data', verbosity=0)
1940 Note that command options that take no arguments are passed as keywords
1942 with True or False, as you can see with the interactive option above.
1943 Named arguments can be passed by using either one of the following syn‐
1945 taxes:
1946 # Similar to the command line
1948 management.call_command('dumpdata', '--natural-foreign')
1949 # Named argument similar to the command line minus the initial dashes and
1951 # with internal dashes replaced by underscores
1952 management.call_command('dumpdata', natural_foreign=True)
1953 # `use_natural_foreign_keys` is the option destination variable
1955 management.call_command('dumpdata', use_natural_foreign_keys=True)
1956 Some command options have different names when using call_command() in‐
1958 stead of django-admin or manage.py. For example, django-admin createsu‐
1959 peruser --no-input translates to call_command('createsuperuser', inter‐
1960 active=False). To find what keyword argument name to use for call_com‐
1961 mand(), check the command's source code for the dest argument passed to
1962 parser.add_argument().
1963 Command options which take multiple options are passed a list:
1965 management.call_command('dumpdata', exclude=['contenttypes', 'auth'])
1967 The return value of the call_command() function is the same as the re‐
1969 turn value of the handle() method of the command.
1970
1972 Note that you can redirect standard output and error streams as all
1973 commands support the stdout and stderr options. For example, you could
1974 write:
1975 with open('/path/to/command_output', 'w') as f:
1977 management.call_command('dumpdata', stdout=f)
1978
1980 Django Software Foundation
1981
1983 Django Software Foundation and contributors
19843.2 April 06, 2021 DJANGO-ADMIN(1)