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
13 DJANGO_SETTINGS_MODULE environment variable so that it points to your
14 project's 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
53 INSTALLED_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, where it is supported, to specify the amount of noti‐
68 fication and debug information 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:
94 django-admin check --database default --database other
96 By default, these checks will not be run.
98 --list-tags
100 Lists all available tags.
102 --deploy
104 Activates some additional checks that are only relevant in a deployment
106 setting.
107 You can use this option in your local development environment, but
109 since your local development settings module may not have many of your
110 production settings, you will probably want to point the check command
111 at a different settings module, either by setting the
112 DJANGO_SETTINGS_MODULE environment variable, or by passing the --set‐
113 tings option:
114 django-admin check --deploy --settings=production_settings
116 Or you could run it directly on a production or staging deployment to
118 verify that the correct settings are in use (omitting --settings). You
119 could even make it part of your integration test suite.
120 --fail-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}
122 Specifies the message level that will cause the command to exit with a
124 non-zero status. Default is ERROR.
125 compilemessages
127 django-admin compilemessages
128 Compiles .po files created by makemessages to .mo files for use with
130 the built-in gettext support. See Internationalization and localiza‐
131 tion.
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 Django's cache framework
172 for more information.
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‐
211 ing command-line client. For example, with PostgreSQL you can use the
212 psql command's -c flag to execute a raw SQL query directly:
213 $ django-admin dbshell -- -c 'select current_user'
215 current_user
216 --------------
217 postgres
218 (1 row)
219 On MySQL/MariaDB, you can do this with the mysql command's -e flag:
221 $ django-admin dbshell -- -e "select user()"
223 +----------------------+
224 | user() |
225 +----------------------+
226 | djangonaut@localhost |
227 +----------------------+
228 NOTE:
230 Be aware that not all options set in the OPTIONS part of your data‐
231 base configuration in DATABASES are passed to the command-line
232 client, e.g. 'isolation_level'.
233 diffsettings
235 django-admin diffsettings
236 Displays differences between the current settings file and Django's de‐
238 fault settings (or another settings file specified by --default).
239 Settings that don't appear in the defaults are followed by "###". For
241 example, the default settings don't define ROOT_URLCONF, so
242 ROOT_URLCONF is followed by "###" in the output of diffsettings.
243 --all
245 Displays all settings, even if they have Django's default value. Such
247 settings are prefixed by "###".
248 --default MODULE
250 The settings module to compare the current settings against. Leave
252 empty to compare against Django's default settings.
253 --output {hash,unified}
255 Specifies the output format. Available values are hash and unified.
257 hash is the default mode that displays the output that's described
258 above. unified displays the output similar to diff -u. Default set‐
259 tings are prefixed with a minus sign, followed by the changed setting
260 prefixed with a plus sign.
261 dumpdata
263 django-admin dumpdata [app_label[.ModelName] [app_label[.ModelName]
264 ...]]
265 Outputs to standard output all data in the database associated with the
267 named application(s).
268 If no application name is provided, all installed applications will be
270 dumped.
271 The output of dumpdata can be used as input for loaddata.
273 When result of dumpdata is saved as a file, it can serve as a fixture
275 for tests or as an initial data.
276 Note that dumpdata uses the default manager on the model for selecting
278 the records to dump. If you're using a custom manager as the default
279 manager and it filters some of the available records, not all of the
280 objects will be dumped.
281 --all, -a
283 Uses Django's base manager, dumping records which might otherwise be
285 filtered or modified by a custom manager.
286 --format FORMAT
288 Specifies the serialization format of the output. Defaults to JSON.
290 Supported formats are listed in Serialization formats.
291 --indent INDENT
293 Specifies the number of indentation spaces to use in the output. De‐
295 faults to None which displays all data on single line.
296 --exclude EXCLUDE, -e EXCLUDE
298 Prevents specific applications or models (specified in the form of
300 app_label.ModelName) from being dumped. If you specify a model name,
301 then only that model will be excluded, rather than the entire applica‐
302 tion. You can also mix application names and model names.
303 If you want to exclude multiple applications, pass --exclude more than
305 once:
306 django-admin dumpdata --exclude=auth --exclude=contenttypes
308 --database DATABASE
310 Specifies the database from which data will be dumped. Defaults to de‐
312 fault.
313 --natural-foreign
315 Uses the natural_key() model method to serialize any foreign key and
317 many-to-many relationship to objects of the type that defines the
318 method. If you're dumping contrib.auth Permission objects or con‐
319 trib.contenttypes ContentType objects, you should probably use this
320 flag. See the natural keys documentation for more details on this and
321 the next option.
322 --natural-primary
324 Omits the primary key in the serialized data of this object since it
326 can be calculated during deserialization.
327 --pks PRIMARY_KEYS
329 Outputs only the objects specified by a comma separated list of primary
331 keys. This is only available when dumping one model. By default, all
332 the records of the model are output.
333 --output OUTPUT, -o OUTPUT
335 Specifies a file to write the serialized data to. By default, the data
337 goes to standard output.
338 When this option is set and --verbosity is greater than 0 (the de‐
340 fault), a progress bar is shown in the terminal.
341 Fixtures compression
343 The output file can be compressed with one of the bz2, gz, lzma, or xz
344 formats by ending the filename with the corresponding extension. For
345 example, to output the data as a compressed JSON file:
346 django-admin dumpdata -o mydata.json.gz
348 flush
350 django-admin flush
351 Removes all data from the database and re-executes any post-synchro‐
353 nization handlers. The table of which migrations have been applied is
354 not cleared.
355 If you would rather start from an empty database and rerun all migra‐
357 tions, you should drop and recreate the database and then run migrate
358 instead.
359 --noinput, --no-input
361 Suppresses all user prompts.
363 --database DATABASE
365 Specifies the database to flush. Defaults to default.
367 inspectdb
369 django-admin inspectdb [table [table ...]]
370 Introspects the database tables in the database pointed-to by the NAME
372 setting and outputs a Django model module (a models.py file) to stan‐
373 dard output.
374 You may choose what tables or views to inspect by passing their names
376 as arguments. If no arguments are provided, models are created for
377 views only if the --include-views option is used. Models for partition
378 tables are created on PostgreSQL if the --include-partitions option is
379 used.
380 Use this if you have a legacy database with which you'd like to use
382 Django. The script will inspect the database and create a model for
383 each table within it.
384 As you might expect, the created models will have an attribute for ev‐
386 ery field in the table. Note that inspectdb has a few special cases in
387 its field-name output:
388 • If inspectdb cannot map a column's type to a model field type, it'll
390 use TextField and will insert the Python comment 'This field type is
391 a guess.' next to the field in the generated model. The recognized
392 fields may depend on apps listed in INSTALLED_APPS. For example,
393 django.contrib.postgres adds recognition for several PostgreSQL-spe‐
394 cific field types.
395 • If the database column name is a Python reserved word (such as
397 'pass', 'class' or 'for'), inspectdb will append '_field' to the at‐
398 tribute name. For example, if a table has a column 'for', the gener‐
399 ated model will have a field 'for_field', with the db_column attri‐
400 bute set to 'for'. inspectdb will insert the Python comment 'Field
401 renamed because it was a Python reserved word.' next to the field.
402 This feature is meant as a shortcut, not as definitive model genera‐
404 tion. After you run it, you'll want to look over the generated models
405 yourself to make customizations. In particular, you'll need to re‐
406 arrange models' order, so that models that refer to other models are
407 ordered properly.
408 Django doesn't create database defaults when a default is specified on
410 a model field. Similarly, database defaults aren't translated to model
411 field defaults or detected in any fashion by inspectdb.
412 By default, inspectdb creates unmanaged models. That is, managed =
414 False in the model's Meta class tells Django not to manage each table's
415 creation, modification, and deletion. If you do want to allow Django to
416 manage the table's lifecycle, you'll need to change the managed option
417 to True (or remove it because True is its default value).
418 Database-specific notes
420 Oracle
421 • Models are created for materialized views if --include-views is used.
422 PostgreSQL
424 • Models are created for foreign tables.
425 • Models are created for materialized views if --include-views is used.
427 • Models are created for partition tables if --include-partitions is
429 used.
430 --database DATABASE
432 Specifies the database to introspect. Defaults to default.
434 --include-partitions
436 If this option is provided, models are also created for partitions.
438 Only support for PostgreSQL is implemented.
440 --include-views
442 If this option is provided, models are also created for database views.
444 loaddata
446 django-admin loaddata fixture [fixture ...]
447 Searches for and loads the contents of the named fixture into the data‐
449 base.
450 --database DATABASE
452 Specifies the database into which the data will be loaded. Defaults to
454 default.
455 --ignorenonexistent, -i
457 Ignores fields and models that may have been removed since the fixture
459 was originally generated.
460 --app APP_LABEL
462 Specifies a single app to look for fixtures in rather than looking in
464 all apps.
465 --format FORMAT
467 Specifies the serialization format (e.g., json or xml) for fixtures
469 read from stdin.
470 --exclude EXCLUDE, -e EXCLUDE
472 Excludes loading the fixtures from the given applications and/or models
474 (in the form of app_label or app_label.ModelName). Use the option mul‐
475 tiple times to exclude more than one app or model.
476 Loading fixtures from stdin
478 You can use a dash as the fixture name to load input from sys.stdin.
479 For example:
480 django-admin loaddata --format=json -
482 When reading from stdin, the --format option is required to specify the
484 serialization format of the input (e.g., json or xml).
485 Loading from stdin is useful with standard input and output redirec‐
487 tions. For example:
488 django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -
490 The dumpdata command can be used to generate input for loaddata.
492 SEE ALSO:
494 For more detail about fixtures see the Fixtures topic.
495 makemessages
497 django-admin makemessages
498 Runs over the entire source tree of the current directory and pulls out
500 all strings marked for translation. It creates (or updates) a message
501 file in the conf/locale (in the Django tree) or locale (for project and
502 application) directory. After making changes to the messages files you
503 need to compile them with compilemessages for use with the builtin get‐
504 text support. See the i18n documentation for details.
505 This command doesn't require configured settings. However, when set‐
507 tings aren't configured, the command can't ignore the MEDIA_ROOT and
508 STATIC_ROOT directories or include LOCALE_PATHS.
509 --all, -a
511 Updates the message files for all available languages.
513 --extension EXTENSIONS, -e EXTENSIONS
515 Specifies a list of file extensions to examine (default: html, txt, py
517 or js if --domain is js).
518 Example usage:
520 django-admin makemessages --locale=de --extension xhtml
522 Separate multiple extensions with commas or use -e or --extension mul‐
524 tiple times:
525 django-admin makemessages --locale=de --extension=html,txt --extension xml
527 --locale LOCALE, -l LOCALE
529 Specifies the locale(s) to process.
531 --exclude EXCLUDE, -x EXCLUDE
533 Specifies the locale(s) to exclude from processing. If not provided, no
535 locales are excluded.
536 Example usage:
538 django-admin makemessages --locale=pt_BR
540 django-admin makemessages --locale=pt_BR --locale=fr
541 django-admin makemessages -l pt_BR
542 django-admin makemessages -l pt_BR -l fr
543 django-admin makemessages --exclude=pt_BR
544 django-admin makemessages --exclude=pt_BR --exclude=fr
545 django-admin makemessages -x pt_BR
546 django-admin makemessages -x pt_BR -x fr
547 --domain DOMAIN, -d DOMAIN
549 Specifies the domain of the messages files. Supported options are:
551 • django for all *.py, *.html and *.txt files (default)
553 • djangojs for *.js files
555 --symlinks, -s
557 Follows symlinks to directories when looking for new translation
559 strings.
560 Example usage:
562 django-admin makemessages --locale=de --symlinks
564 --ignore PATTERN, -i PATTERN
566 Ignores files or directories matching the given glob-style pattern. Use
568 multiple times to ignore more.
569 These patterns are used by default: 'CVS', '.*', '*~', '*.pyc'.
571 Example usage:
573 django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html
575 --no-default-ignore
577 Disables the default values of --ignore.
579 --no-wrap
581 Disables breaking long message lines into several lines in language
583 files.
584 --no-location
586 Suppresses writing '#: filename:line’ comment lines in language files.
588 Using this option makes it harder for technically skilled translators
589 to understand each message's context.
590 --add-location [{full,file,never}]
592 Controls #: filename:line comment lines in language files. If the op‐
594 tion is:
595 • full (the default if not given): the lines include both file name and
597 line number.
598 • file: the line number is omitted.
600 • never: the lines are suppressed (same as --no-location).
602 Requires gettext 0.19 or newer.
604 --keep-pot
606 Prevents deleting the temporary .pot files generated before creating
608 the .po file. This is useful for debugging errors which may prevent the
609 final language files from being created.
610 SEE ALSO:
612 See Customizing the makemessages command for instructions on how to
613 customize the keywords that makemessages passes to xgettext.
614 makemigrations
616 django-admin makemigrations [app_label [app_label ...]]
617 Creates new migrations based on the changes detected to your models.
619 Migrations, their relationship with apps and more are covered in depth
620 in the migrations documentation.
621 Providing one or more app names as arguments will limit the migrations
623 created to the app(s) specified and any dependencies needed (the table
624 at the other end of a ForeignKey, for example).
625 To add migrations to an app that doesn't have a migrations directory,
627 run makemigrations with the app's app_label.
628 --noinput, --no-input
630 Suppresses all user prompts. If a suppressed prompt cannot be resolved
632 automatically, the command will exit with error code 3.
633 --empty
635 Outputs an empty migration for the specified apps, for manual editing.
637 This is for advanced users and should not be used unless you are famil‐
638 iar with the migration format, migration operations, and the dependen‐
639 cies between your migrations.
640 --dry-run
642 Shows what migrations would be made without actually writing any migra‐
644 tions files to disk. Using this option along with --verbosity 3 will
645 also show the complete migrations files that would be written.
646 --merge
648 Enables fixing of migration conflicts.
650 --name NAME, -n NAME
652 Allows naming the generated migration(s) instead of using a generated
654 name. The name must be a valid Python identifier.
655 --no-header
657 Generate migration files without Django version and timestamp header.
659 --check
661 Makes makemigrations exit with a non-zero status when model changes
663 without migrations are detected.
664 In older versions, the missing migrations were also created when using
666 the --check option.
667 --scriptable
670 Diverts log output and input prompts to stderr, writing only paths of
674 generated migration files to stdout.
675 --update
677 Merges model changes into the latest migration and optimize the result‐
681 ing operations.
682 migrate
684 django-admin migrate [app_label] [migration_name]
685 Synchronizes the database state with the current set of models and mi‐
687 grations. Migrations, their relationship with apps and more are cov‐
688 ered in depth in the migrations documentation.
689 The behavior of this command changes depending on the arguments pro‐
691 vided:
692 • No arguments: All apps have all of their migrations run.
694 • <app_label>: The specified app has its migrations run, up to the most
696 recent migration. This may involve running other apps' migrations
697 too, due to dependencies.
698 • <app_label> <migrationname>: Brings the database schema to a state
700 where the named migration is applied, but no later migrations in the
701 same app are applied. This may involve unapplying migrations if you
702 have previously migrated past the named migration. You can use a pre‐
703 fix of the migration name, e.g. 0001, as long as it's unique for the
704 given app name. Use the name zero to migrate all the way back i.e. to
705 revert all applied migrations for an app.
706 WARNING:
708 When unapplying migrations, all dependent migrations will also be
709 unapplied, regardless of <app_label>. You can use --plan to check
710 which migrations will be unapplied.
711 --database DATABASE
713 Specifies the database to migrate. Defaults to default.
715 --fake
717 Marks the migrations up to the target one (following the rules above)
719 as applied, but without actually running the SQL to change your data‐
720 base schema.
721 This is intended for advanced users to manipulate the current migration
723 state directly if they're manually applying changes; be warned that us‐
724 ing --fake runs the risk of putting the migration state table into a
725 state where manual recovery will be needed to make migrations run cor‐
726 rectly.
727 --fake-initial
729 Allows Django to skip an app's initial migration if all database tables
731 with the names of all models created by all CreateModel operations in
732 that migration already exist. This option is intended for use when
733 first running migrations against a database that preexisted the use of
734 migrations. This option does not, however, check for matching database
735 schema beyond matching table names and so is only safe to use if you
736 are confident that your existing schema matches what is recorded in
737 your initial migration.
738 --plan
740 Shows the migration operations that will be performed for the given mi‐
742 grate command.
743 --run-syncdb
745 Allows creating tables for apps without migrations. While this isn't
747 recommended, the migrations framework is sometimes too slow on large
748 projects with hundreds of models.
749 --noinput, --no-input
751 Suppresses all user prompts. An example prompt is asking about removing
753 stale content types.
754 --check
756 Makes migrate exit with a non-zero status when unapplied migrations are
758 detected.
759 --prune
761 Deletes nonexistent migrations from the django_migrations table. This
765 is useful when migration files replaced by a squashed migration have
766 been removed. See Squashing migrations for more details.
767 optimizemigration
769 django-admin optimizemigration app_label migration_name
770 Optimizes the operations for the named migration and overrides the ex‐
772 isting file. If the migration contains functions that must be manually
773 copied, the command creates a new migration file suffixed with _opti‐
774 mized that is meant to replace the named migration.
775 --check
777 Makes optimizemigration exit with a non-zero status when a migration
779 can be optimized.
780 runserver
782 django-admin runserver [addrport]
783 Starts a lightweight development web server on the local machine. By
785 default, the server runs on port 8000 on the IP address 127.0.0.1. You
786 can pass in an IP address and port number explicitly.
787 If you run this script as a user with normal privileges (recommended),
789 you might not have access to start a port on a low port number. Low
790 port numbers are reserved for the superuser (root).
791 This server uses the WSGI application object specified by the
793 WSGI_APPLICATION setting.
794 DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through
796 security audits or performance tests. (And that's how it's gonna stay.
797 We're in the business of making web frameworks, not web servers, so im‐
798 proving this server to be able to handle a production environment is
799 outside the scope of Django.)
800 The development server automatically reloads Python code for each re‐
802 quest, as needed. You don't need to restart the server for code changes
803 to take effect. However, some actions like adding files don't trigger
804 a restart, so you'll have to restart the server in these cases.
805 If you're using Linux or MacOS and install both pywatchman and the
807 Watchman service, kernel signals will be used to autoreload the server
808 (rather than polling file modification timestamps each second). This
809 offers better performance on large projects, reduced response time af‐
810 ter code changes, more robust change detection, and a reduction in
811 power usage. Django supports pywatchman 1.2.0 and higher.
812 Large directories with many files may cause performance issues
814 When using Watchman with a project that includes large
816 non-Python directories like node_modules, it's advisable to
817 ignore this directory for optimal performance. See the
818 watchman documentation for information on how to do this.
819 Watchman timeout
821 DJANGO_WATCHMAN_TIMEOUT
823 The default timeout of Watchman client is 5 seconds. You can change
825 it by setting the DJANGO_WATCHMAN_TIMEOUT environment variable.
826 When you start the server, and each time you change Python code while
828 the server is running, the system check framework will check your en‐
829 tire Django project for some common errors (see the check command). If
830 any errors are found, they will be printed to standard output. You can
831 use the --skip-checks option to skip running system checks.
832 You can run as many concurrent servers as you want, as long as they're
834 on separate ports by executing django-admin runserver more than once.
835 Note that the default IP address, 127.0.0.1, is not accessible from
837 other machines on your network. To make your development server view‐
838 able to other machines on the network, use its own IP address (e.g.
839 192.168.2.1), 0 (shortcut for 0.0.0.0), 0.0.0.0, or :: (with IPv6 en‐
840 abled).
841 You can provide an IPv6 address surrounded by brackets (e.g.
843 [200a::1]:8000). This will automatically enable IPv6 support.
844 A hostname containing ASCII-only characters can also be used.
846 If the staticfiles contrib app is enabled (default in new projects) the
848 runserver command will be overridden with its own runserver command.
849 Logging of each request and response of the server is sent to the
851 django.server logger.
852 --noreload
854 Disables the auto-reloader. This means any Python code changes you make
856 while the server is running will not take effect if the particular
857 Python modules have already been loaded into memory.
858 --nothreading
860 Disables use of threading in the development server. The server is mul‐
862 tithreaded by default.
863 --ipv6, -6
865 Uses IPv6 for the development server. This changes the default IP ad‐
867 dress from 127.0.0.1 to ::1.
868 Examples of using different ports and addresses
870 Port 8000 on IP address 127.0.0.1:
871 django-admin runserver
873 Port 8000 on IP address 1.2.3.4:
875 django-admin runserver 1.2.3.4:8000
877 Port 7000 on IP address 127.0.0.1:
879 django-admin runserver 7000
881 Port 7000 on IP address 1.2.3.4:
883 django-admin runserver 1.2.3.4:7000
885 Port 8000 on IPv6 address ::1:
887 django-admin runserver -6
889 Port 7000 on IPv6 address ::1:
891 django-admin runserver -6 7000
893 Port 7000 on IPv6 address 2001:0db8:1234:5678::9:
895 django-admin runserver [2001:0db8:1234:5678::9]:7000
897 Port 8000 on IPv4 address of host localhost:
899 django-admin runserver localhost:8000
901 Port 8000 on IPv6 address of host localhost:
903 django-admin runserver -6 localhost:8000
905 Serving static files with the development server
907 By default, the development server doesn't serve any static files for
908 your site (such as CSS files, images, things under MEDIA_URL and so
909 forth). If you want to configure Django to serve static media, read How
910 to manage static files (e.g. images, JavaScript, CSS).
911 Serving with ASGI in development
913 Django's runserver command provides a WSGI server. In order to run un‐
914 der ASGI you will need to use an ASGI server. The Django Daphne
915 project provides Integration with runserver that you can use.
916 sendtestemail
918 django-admin sendtestemail [email [email ...]]
919 Sends a test email (to confirm email sending through Django is working)
921 to the recipient(s) specified. For example:
922 django-admin sendtestemail foo@example.com bar@example.com
924 There are a couple of options, and you may use any combination of them
926 together:
927 --managers
929 Mails the email addresses specified in MANAGERS using mail_managers().
931 --admins
933 Mails the email addresses specified in ADMINS using mail_admins().
935 shell
937 django-admin shell
938 Starts the Python interactive interpreter.
940 --interface {ipython,bpython,python}, -i {ipython,bpython,python}
942 Specifies the shell to use. By default, Django will use IPython or
944 bpython if either is installed. If both are installed, specify which
945 one you want like so:
946 IPython:
948 django-admin shell -i ipython
950 bpython:
952 django-admin shell -i bpython
954 If you have a "rich" shell installed but want to force use of the
956 "plain" Python interpreter, use python as the interface name, like so:
957 django-admin shell -i python
959 --nostartup
961 Disables reading the startup script for the "plain" Python interpreter.
963 By default, the script pointed to by the PYTHONSTARTUP environment
964 variable or the ~/.pythonrc.py script is read.
965 --command COMMAND, -c COMMAND
967 Lets you pass a command as a string to execute it as Django, like so:
969 django-admin shell --command="import django; print(django.__version__)"
971 You can also pass code in on standard input to execute it. For example:
973 $ django-admin shell <<EOF
975 > import django
976 > print(django.__version__)
977 > EOF
978 On Windows, the REPL is output due to implementation limits of
980 select.select() on that platform.
981 showmigrations
983 django-admin showmigrations [app_label [app_label ...]]
984 Shows all migrations in a project. You can choose from one of two for‐
986 mats:
987 --list, -l
989 Lists all of the apps Django knows about, the migrations available for
991 each app, and whether or not each migration is applied (marked by an
992 [X] next to the migration name). For a --verbosity of 2 and above, the
993 applied datetimes are also shown.
994 Apps without migrations are also listed, but have (no migrations)
996 printed under them.
997 This is the default output format.
999 --plan, -p
1001 Shows the migration plan Django will follow to apply migrations. Like
1003 --list, applied migrations are marked by an [X]. For a --verbosity of 2
1004 and above, all dependencies of a migration will also be shown.
1005 app_labels arguments limit the output, however, dependencies of pro‐
1007 vided apps may also be included.
1008 --database DATABASE
1010 Specifies the database to examine. Defaults to default.
1012 sqlflush
1014 django-admin sqlflush
1015 Prints the SQL statements that would be executed for the flush command.
1017 --database DATABASE
1019 Specifies the database for which to print the SQL. Defaults to default.
1021 sqlmigrate
1023 django-admin sqlmigrate app_label migration_name
1024 Prints the SQL for the named migration. This requires an active data‐
1026 base connection, which it will use to resolve constraint names; this
1027 means you must generate the SQL against a copy of the database you wish
1028 to later apply it on.
1029 Note that sqlmigrate doesn't colorize its output.
1031 --backwards
1033 Generates the SQL for unapplying the migration. By default, the SQL
1035 created is for running the migration in the forwards direction.
1036 --database DATABASE
1038 Specifies the database for which to generate the SQL. Defaults to de‐
1040 fault.
1041 sqlsequencereset
1043 django-admin sqlsequencereset app_label [app_label ...]
1044 Prints the SQL statements for resetting sequences for the given app
1046 name(s).
1047 Sequences are indexes used by some database engines to track the next
1049 available number for automatically incremented fields.
1050 Use this command to generate SQL which will fix cases where a sequence
1052 is out of sync with its automatically incremented field data.
1053 --database DATABASE
1055 Specifies the database for which to print the SQL. Defaults to default.
1057 squashmigrations
1059 django-admin squashmigrations app_label [start_migration_name] migra‐
1060 tion_name
1061 Squashes the migrations for app_label up to and including migra‐
1063 tion_name down into fewer migrations, if possible. The resulting
1064 squashed migrations can live alongside the unsquashed ones safely. For
1065 more information, please read Squashing migrations.
1066 When start_migration_name is given, Django will only include migrations
1068 starting from and including this migration. This helps to mitigate the
1069 squashing limitation of RunPython and
1070 django.db.migrations.operations.RunSQL migration operations.
1071 --no-optimize
1073 Disables the optimizer when generating a squashed migration. By de‐
1075 fault, Django will try to optimize the operations in your migrations to
1076 reduce the size of the resulting file. Use this option if this process
1077 is failing or creating incorrect migrations, though please also file a
1078 Django bug report about the behavior, as optimization is meant to be
1079 safe.
1080 --noinput, --no-input
1082 Suppresses all user prompts.
1084 --squashed-name SQUASHED_NAME
1086 Sets the name of the squashed migration. When omitted, the name is
1088 based on the first and last migration, with _squashed_ in between.
1089 --no-header
1091 Generate squashed migration file without Django version and timestamp
1093 header.
1094 startapp
1096 django-admin startapp name [directory]
1097 Creates a Django app directory structure for the given app name in the
1099 current directory or the given destination.
1100 By default, the new directory contains a models.py file and other app
1102 template files. If only the app name is given, the app directory will
1103 be created in the current working directory.
1104 If the optional destination is provided, Django will use that existing
1106 directory rather than creating a new one. You can use '.' to denote the
1107 current working directory.
1108 For example:
1110 django-admin startapp myapp /Users/jezdez/Code/myapp
1112 --template TEMPLATE
1114 Provides the path to a directory with a custom app template file, or a
1116 path to an uncompressed archive (.tar) or a compressed archive
1117 (.tar.gz, .tar.bz2, .tar.xz, .tar.lzma, .tgz, .tbz2, .txz, .tlz, .zip)
1118 containing the app template files.
1119 For example, this would look for an app template in the given directory
1121 when creating the myapp app:
1122 django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp
1124 Django will also accept URLs (http, https, ftp) to compressed archives
1126 with the app template files, downloading and extracting them on the
1127 fly.
1128 For example, taking advantage of GitHub's feature to expose reposito‐
1130 ries as zip files, you can use a URL like:
1131 django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/main.zip myapp
1133 --extension EXTENSIONS, -e EXTENSIONS
1135 Specifies which file extensions in the app template should be rendered
1137 with the template engine. Defaults to py.
1138 --name FILES, -n FILES
1140 Specifies which files in the app template (in addition to those match‐
1142 ing --extension) should be rendered with the template engine. Defaults
1143 to an empty list.
1144 --exclude DIRECTORIES, -x DIRECTORIES
1146 Specifies which directories in the app template should be excluded, in
1148 addition to .git and __pycache__. If this option is not provided, di‐
1149 rectories named __pycache__ or starting with . will be excluded.
1150 The template context used for all matching files is:
1152 • Any option passed to the startapp command (among the command's sup‐
1154 ported options)
1155 • app_name -- the app name as passed to the command
1157 • app_directory -- the full path of the newly created app
1159 • camel_case_app_name -- the app name in camel case format
1161 • docs_version -- the version of the documentation: 'dev' or '1.x'
1163 • django_version -- the version of Django, e.g. '2.0.3'
1165 WARNING:
1167 When the app template files are rendered with the Django template
1168 engine (by default all *.py files), Django will also replace all
1169 stray template variables contained. For example, if one of the
1170 Python files contains a docstring explaining a particular feature
1171 related to template rendering, it might result in an incorrect exam‐
1172 ple.
1173 To work around this problem, you can use the templatetag template
1175 tag to "escape" the various parts of the template syntax.
1176 In addition, to allow Python template files that contain Django tem‐
1178 plate language syntax while also preventing packaging systems from
1179 trying to byte-compile invalid *.py files, template files ending
1180 with .py-tpl will be renamed to .py.
1181 WARNING:
1183 The contents of custom app (or project) templates should always be
1184 audited before use: Such templates define code that will become part
1185 of your project, and this means that such code will be trusted as
1186 much as any app you install, or code you write yourself. Further,
1187 even rendering the templates is, effectively, executing code that
1188 was provided as input to the management command. The Django template
1189 language may provide wide access into the system, so make sure any
1190 custom template you use is worthy of your trust.
1191 startproject
1193 django-admin startproject name [directory]
1194 Creates a Django project directory structure for the given project name
1196 in the current directory or the given destination.
1197 By default, the new directory contains manage.py and a project package
1199 (containing a settings.py and other files).
1200 If only the project name is given, both the project directory and
1202 project package will be named <projectname> and the project directory
1203 will be created in the current working directory.
1204 If the optional destination is provided, Django will use that existing
1206 directory as the project directory, and create manage.py and the
1207 project package within it. Use '.' to denote the current working direc‐
1208 tory.
1209 For example:
1211 django-admin startproject myproject /Users/jezdez/Code/myproject_repo
1213 --template TEMPLATE
1215 Specifies a directory, file path, or URL of a custom project template.
1217 See the startapp --template documentation for examples and usage.
1218 --extension EXTENSIONS, -e EXTENSIONS
1220 Specifies which file extensions in the project template should be ren‐
1222 dered with the template engine. Defaults to py.
1223 --name FILES, -n FILES
1225 Specifies which files in the project template (in addition to those
1227 matching --extension) should be rendered with the template engine. De‐
1228 faults to an empty list.
1229 --exclude DIRECTORIES, -x DIRECTORIES
1231 Specifies which directories in the project template should be excluded,
1233 in addition to .git and __pycache__. If this option is not provided,
1234 directories named __pycache__ or starting with . will be excluded.
1235 The template context used is:
1237 • Any option passed to the startproject command (among the command's
1239 supported options)
1240 • project_name -- the project name as passed to the command
1242 • project_directory -- the full path of the newly created project
1244 • secret_key -- a random key for the SECRET_KEY setting
1246 • docs_version -- the version of the documentation: 'dev' or '1.x'
1248 • django_version -- the version of Django, e.g. '2.0.3'
1250 Please also see the rendering warning and trusted code warning as men‐
1252 tioned for startapp.
1253 test
1255 django-admin test [test_label [test_label ...]]
1256 Runs tests for all installed apps. See Testing in Django for more in‐
1258 formation.
1259 --failfast
1261 Stops running tests and reports the failure immediately after a test
1263 fails.
1264 --testrunner TESTRUNNER
1266 Controls the test runner class that is used to execute tests. This
1268 value overrides the value provided by the TEST_RUNNER setting.
1269 --noinput, --no-input
1271 Suppresses all user prompts. A typical prompt is a warning about delet‐
1273 ing an existing test database.
1274 Test runner options
1276 The test command receives options on behalf of the specified
1277 --testrunner. These are the options of the default test runner:
1278 DiscoverRunner.
1279 --keepdb
1281 Preserves the test database between test runs. This has the advantage
1283 of skipping both the create and destroy actions which can greatly de‐
1284 crease the time to run tests, especially those in a large test suite.
1285 If the test database does not exist, it will be created on the first
1286 run and then preserved for each subsequent run. Unless the MIGRATE test
1287 setting is False, any unapplied migrations will also be applied to the
1288 test database before running the test suite.
1289 --shuffle [SEED]
1291 Randomizes the order of tests before running them. This can help detect
1293 tests that aren't properly isolated. The test order generated by this
1294 option is a deterministic function of the integer seed given. When no
1295 seed is passed, a seed is chosen randomly and printed to the console.
1296 To repeat a particular test order, pass a seed. The test orders gener‐
1297 ated by this option preserve Django's guarantees on test order. They
1298 also keep tests grouped by test case class.
1299 The shuffled orderings also have a special consistency property useful
1301 when narrowing down isolation issues. Namely, for a given seed and when
1302 running a subset of tests, the new order will be the original shuffling
1303 restricted to the smaller set. Similarly, when adding tests while keep‐
1304 ing the seed the same, the order of the original tests will be the same
1305 in the new order.
1306 --reverse, -r
1308 Sorts test cases in the opposite execution order. This may help in de‐
1310 bugging the side effects of tests that aren't properly isolated.
1311 Grouping by test class is preserved when using this option. This can be
1312 used in conjunction with --shuffle to reverse the order for a particu‐
1313 lar seed.
1314 --debug-mode
1316 Sets the DEBUG setting to True prior to running tests. This may help
1318 troubleshoot test failures.
1319 --debug-sql, -d
1321 Enables SQL logging for failing tests. If --verbosity is 2, then
1323 queries in passing tests are also output.
1324 --parallel [N]
1326 DJANGO_TEST_PROCESSES
1328 Runs tests in separate parallel processes. Since modern processors have
1330 multiple cores, this allows running tests significantly faster.
1331 Using --parallel without a value, or with the value auto, runs one test
1333 process per core according to multiprocessing.cpu_count(). You can
1334 override this by passing the desired number of processes, e.g. --par‐
1335 allel 4, or by setting the DJANGO_TEST_PROCESSES environment variable.
1336 Django distributes test cases — unittest.TestCase subclasses — to sub‐
1338 processes. If there are fewer test cases than configured processes,
1339 Django will reduce the number of processes accordingly.
1340 Each process gets its own database. You must ensure that different test
1342 cases don't access the same resources. For instance, test cases that
1343 touch the filesystem should create a temporary directory for their own
1344 use.
1345 NOTE:
1347 If you have test classes that cannot be run in parallel, you can use
1348 SerializeMixin to run them sequentially. See Enforce running test
1349 classes sequentially.
1350 This option requires the third-party tblib package to display trace‐
1352 backs correctly:
1353 $ python -m pip install tblib
1355 This feature isn't available on Windows. It doesn't work with the Ora‐
1357 cle database backend either.
1358 If you want to use pdb while debugging tests, you must disable parallel
1360 execution (--parallel=1). You'll see something like bdb.BdbQuit if you
1361 don't.
1362 WARNING:
1364 When test parallelization is enabled and a test fails, Django may be
1365 unable to display the exception traceback. This can make debugging
1366 difficult. If you encounter this problem, run the affected test
1367 without parallelization to see the traceback of the failure.
1368 This is a known limitation. It arises from the need to serialize ob‐
1370 jects in order to exchange them between processes. See What can be
1371 pickled and unpickled? for details.
1372 --tag TAGS
1374 Runs only tests marked with the specified tags. May be specified mul‐
1376 tiple times and combined with test --exclude-tag.
1377 Tests that fail to load are always considered matching.
1379 --exclude-tag EXCLUDE_TAGS
1381 Excludes tests marked with the specified tags. May be specified multi‐
1383 ple times and combined with test --tag.
1384 -k TEST_NAME_PATTERNS
1386 Runs test methods and classes matching test name patterns, in the same
1388 way as unittest's -k option. Can be specified multiple times.
1389 --pdb
1391 Spawns a pdb debugger at each test error or failure. If you have it in‐
1393 stalled, ipdb is used instead.
1394 --buffer, -b
1396 Discards output (stdout and stderr) for passing tests, in the same way
1398 as unittest's --buffer option.
1399 --no-faulthandler
1401 Django automatically calls faulthandler.enable() when starting the
1403 tests, which allows it to print a traceback if the interpreter crashes.
1404 Pass --no-faulthandler to disable this behavior.
1405 --timing
1407 Outputs timings, including database setup and total run time.
1409 testserver
1411 django-admin testserver [fixture [fixture ...]]
1412 Runs a Django development server (as in runserver) using data from the
1414 given fixture(s).
1415 For example, this command:
1417 django-admin testserver mydata.json
1419 ...would perform the following steps:
1421 1. Create a test database, as described in The test database.
1423 2. Populate the test database with fixture data from the given fix‐
1425 tures. (For more on fixtures, see the documentation for loaddata
1426 above.)
1427 3. Runs the Django development server (as in runserver), pointed at
1429 this newly created test database instead of your production data‐
1430 base.
1431 This is useful in a number of ways:
1433 • When you're writing unit tests of how your views act with certain
1435 fixture data, you can use testserver to interact with the views in a
1436 web browser, manually.
1437 • Let's say you're developing your Django application and have a "pris‐
1439 tine" copy of a database that you'd like to interact with. You can
1440 dump your database to a fixture (using the dumpdata command, ex‐
1441 plained above), then use testserver to run your web application with
1442 that data. With this arrangement, you have the flexibility of mess‐
1443 ing up your data in any way, knowing that whatever data changes
1444 you're making are only being made to a test database.
1445 Note that this server does not automatically detect changes to your
1447 Python source code (as runserver does). It does, however, detect
1448 changes to templates.
1449 --addrport ADDRPORT
1451 Specifies a different port, or IP address and port, from the default of
1453 127.0.0.1:8000. This value follows exactly the same format and serves
1454 exactly the same function as the argument to the runserver command.
1455 Examples:
1457 To run the test server on port 7000 with fixture1 and fixture2:
1459 django-admin testserver --addrport 7000 fixture1 fixture2
1461 django-admin testserver fixture1 fixture2 --addrport 7000
1462 (The above statements are equivalent. We include both of them to demon‐
1464 strate that it doesn't matter whether the options come before or after
1465 the fixture arguments.)
1466 To run on 1.2.3.4:7000 with a test fixture:
1468 django-admin testserver --addrport 1.2.3.4:7000 test
1470 --noinput, --no-input
1472 Suppresses all user prompts. A typical prompt is a warning about delet‐
1474 ing an existing test database.
1475
1477 Some commands are only available when the django.contrib application
1478 that implements them has been enabled. This section describes them
1479 grouped by their application.
1480 django.contrib.auth
1482 changepassword
1483 django-admin changepassword [<username>]
1484 This command is only available if Django's authentication system
1486 (django.contrib.auth) is installed.
1487 Allows changing a user's password. It prompts you to enter a new pass‐
1489 word twice for the given user. If the entries are identical, this imme‐
1490 diately becomes the new password. If you do not supply a user, the com‐
1491 mand will attempt to change the password whose username matches the
1492 current user.
1493 --database DATABASE
1495 Specifies the database to query for the user. Defaults to default.
1497 Example usage:
1499 django-admin changepassword ringo
1501 createsuperuser
1503 django-admin createsuperuser
1504 DJANGO_SUPERUSER_PASSWORD
1506 This command is only available if Django's authentication system
1508 (django.contrib.auth) is installed.
1509 Creates a superuser account (a user who has all permissions). This is
1511 useful if you need to create an initial superuser account or if you
1512 need to programmatically generate superuser accounts for your site(s).
1513 When run interactively, this command will prompt for a password for the
1515 new superuser account. When run non-interactively, you can provide a
1516 password by setting the DJANGO_SUPERUSER_PASSWORD environment variable.
1517 Otherwise, no password will be set, and the superuser account will not
1518 be able to log in until a password has been manually set for it.
1519 In non-interactive mode, the USERNAME_FIELD and required fields (listed
1521 in REQUIRED_FIELDS) fall back to DJANGO_SUPERUSER_<upper‐
1522 case_field_name> environment variables, unless they are overridden by a
1523 command line argument. For example, to provide an email field, you can
1524 use DJANGO_SUPERUSER_EMAIL environment variable.
1525 --noinput, --no-input
1527 Suppresses all user prompts. If a suppressed prompt cannot be resolved
1529 automatically, the command will exit with error code 1.
1530 --username USERNAME
1532 --email EMAIL
1534 The username and email address for the new account can be supplied by
1536 using the --username and --email arguments on the command line. If ei‐
1537 ther of those is not supplied, createsuperuser will prompt for it when
1538 running interactively.
1539 --database DATABASE
1541 Specifies the database into which the superuser object will be saved.
1543 You can subclass the management command and override get_input_data()
1545 if you want to customize data input and validation. Consult the source
1546 code for details on the existing implementation and the method's param‐
1547 eters. For example, it could be useful if you have a ForeignKey in
1548 REQUIRED_FIELDS and want to allow creating an instance instead of en‐
1549 tering the primary key of an existing instance.
1550 django.contrib.contenttypes
1552 remove_stale_contenttypes
1553 django-admin remove_stale_contenttypes
1554 This command is only available if Django's contenttypes app (‐
1556 django.contrib.contenttypes) is installed.
1557 Deletes stale content types (from deleted models) in your database. Any
1559 objects that depend on the deleted content types will also be deleted.
1560 A list of deleted objects will be displayed before you confirm it's
1561 okay to proceed with the deletion.
1562 --database DATABASE
1564 Specifies the database to use. Defaults to default.
1566 --include-stale-apps
1568 Deletes stale content types including ones from previously installed
1570 apps that have been removed from INSTALLED_APPS. Defaults to False.
1571 django.contrib.gis
1573 ogrinspect
1574 This command is only available if GeoDjango (django.contrib.gis) is in‐
1575 stalled.
1576 Please refer to its description in the GeoDjango documentation.
1578 django.contrib.sessions
1580 clearsessions
1581 django-admin clearsessions
1582 Can be run as a cron job or directly to clean out expired sessions.
1584 django.contrib.sitemaps
1586 ping_google
1587 This command is only available if the Sitemaps framework (django.con‐
1588 trib.sitemaps) is installed.
1589 Please refer to its description in the Sitemaps documentation.
1591 django.contrib.staticfiles
1593 collectstatic
1594 This command is only available if the static files application
1595 (django.contrib.staticfiles) is installed.
1596 Please refer to its description in the staticfiles documentation.
1598 findstatic
1600 This command is only available if the static files application
1601 (django.contrib.staticfiles) is installed.
1602 Please refer to its description in the staticfiles documentation.
1604
1606 Although some commands may allow their own custom options, every com‐
1607 mand allows for the following options by default:
1608 --pythonpath PYTHONPATH
1610 Adds the given filesystem path to the Python import search path. If
1612 this isn't provided, django-admin will use the PYTHONPATH environment
1613 variable.
1614 This option is unnecessary in manage.py, because it takes care of set‐
1616 ting the Python path for you.
1617 Example usage:
1619 django-admin migrate --pythonpath='/home/djangoprojects/myproject'
1621 --settings SETTINGS
1623 Specifies the settings module to use. The settings module should be in
1625 Python package syntax, e.g. mysite.settings. If this isn't provided,
1626 django-admin will use the DJANGO_SETTINGS_MODULE environment variable.
1627 This option is unnecessary in manage.py, because it uses settings.py
1629 from the current project by default.
1630 Example usage:
1632 django-admin migrate --settings=mysite.settings
1634 --traceback
1636 Displays a full stack trace when a CommandError is raised. By default,
1638 django-admin will show an error message when a CommandError occurs and
1639 a full stack trace for any other exception.
1640 This option is ignored by runserver.
1642 Example usage:
1644 django-admin migrate --traceback
1646 --verbosity {0,1,2,3}, -v {0,1,2,3}
1648 Specifies the amount of notification and debug information that a com‐
1650 mand should print to the console.
1651 • 0 means no output.
1653 • 1 means normal output (default).
1655 • 2 means verbose output.
1657 • 3 means very verbose output.
1659 This option is ignored by runserver.
1661 Example usage:
1663 django-admin migrate --verbosity 2
1665 --no-color
1667 Disables colorized command output. Some commands format their output
1669 to be colorized. For example, errors will be printed to the console in
1670 red and SQL statements will be syntax highlighted.
1671 Example usage:
1673 django-admin runserver --no-color
1675 --force-color
1677 Forces colorization of the command output if it would otherwise be dis‐
1679 abled as discussed in Syntax coloring. For example, you may want to
1680 pipe colored output to another command.
1681 --skip-checks
1683 Skips running system checks prior to running the command. This option
1685 is only available if the requires_system_checks command attribute is
1686 not an empty list or tuple.
1687 Example usage:
1689 django-admin migrate --skip-checks
1691
1693 Syntax coloring
1694 DJANGO_COLORS
1695 The django-admin / manage.py commands will use pretty color-coded out‐
1697 put if your terminal supports ANSI-colored output. It won't use the
1698 color codes if you're piping the command's output to another program
1699 unless the --force-color option is used.
1700 Windows support
1702 On Windows 10, the Windows Terminal application, VS Code, and Power‐
1703 Shell (where virtual terminal processing is enabled) allow colored out‐
1704 put, and are supported by default.
1705 Under Windows, the legacy cmd.exe native console doesn't support ANSI
1707 escape sequences so by default there is no color output. In this case
1708 either of two third-party libraries are needed:
1709 • Install colorama, a Python package that translates ANSI color codes
1711 into Windows API calls. Django commands will detect its presence and
1712 will make use of its services to color output just like on Unix-based
1713 platforms. colorama can be installed via pip:
1714 ...\> py -m pip install colorama
1716 • Install ANSICON, a third-party tool that allows cmd.exe to process
1718 ANSI color codes. Django commands will detect its presence and will
1719 make use of its services to color output just like on Unix-based
1720 platforms.
1721 Other modern terminal environments on Windows, that support terminal
1723 colors, but which are not automatically detected as supported by
1724 Django, may "fake" the installation of ANSICON by setting the appropri‐
1725 ate environmental variable, ANSICON="on".
1726 Custom colors
1728 The colors used for syntax highlighting can be customized. Django ships
1729 with three color palettes:
1730 • dark, suited to terminals that show white text on a black background.
1732 This is the default palette.
1733 • light, suited to terminals that show black text on a white back‐
1735 ground.
1736 • nocolor, which disables syntax highlighting.
1738 You select a palette by setting a DJANGO_COLORS environment variable to
1740 specify the palette you want to use. For example, to specify the light
1741 palette under a Unix or OS/X BASH shell, you would run the following at
1742 a command prompt:
1743 export DJANGO_COLORS="light"
1745 You can also customize the colors that are used. Django specifies a
1747 number of roles in which color is used:
1748 • error - A major error.
1750 • notice - A minor error.
1752 • success - A success.
1754 • warning - A warning.
1756 • sql_field - The name of a model field in SQL.
1758 • sql_coltype - The type of a model field in SQL.
1760 • sql_keyword - An SQL keyword.
1762 • sql_table - The name of a model in SQL.
1764 • http_info - A 1XX HTTP Informational server response.
1766 • http_success - A 2XX HTTP Success server response.
1768 • http_not_modified - A 304 HTTP Not Modified server response.
1770 • http_redirect - A 3XX HTTP Redirect server response other than 304.
1772 • http_not_found - A 404 HTTP Not Found server response.
1774 • http_bad_request - A 4XX HTTP Bad Request server response other than
1776 404.
1777 • http_server_error - A 5XX HTTP Server Error response.
1779 • migrate_heading - A heading in a migrations management command.
1781 • migrate_label - A migration name.
1783 Each of these roles can be assigned a specific foreground and back‐
1785 ground color, from the following list:
1786 • black
1788 • red
1790 • green
1792 • yellow
1794 • blue
1796 • magenta
1798 • cyan
1800 • white
1802 Each of these colors can then be modified by using the following dis‐
1804 play options:
1805 • bold
1807 • underscore
1809 • blink
1811 • reverse
1813 • conceal
1815 A color specification follows one of the following patterns:
1817 • role=fg
1819 • role=fg/bg
1821 • role=fg,option,option
1823 • role=fg/bg,option,option
1825 where role is the name of a valid color role, fg is the foreground
1827 color, bg is the background color and each option is one of the color
1828 modifying options. Multiple color specifications are then separated by
1829 a semicolon. For example:
1830 export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
1832 would specify that errors be displayed using blinking yellow on blue,
1834 and notices displayed using magenta. All other color roles would be
1835 left uncolored.
1836 Colors can also be specified by extending a base palette. If you put a
1838 palette name in a color specification, all the colors implied by that
1839 palette will be loaded. So:
1840 export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
1842 would specify the use of all the colors in the light color palette, ex‐
1844 cept for the colors for errors and notices which would be overridden as
1845 specified.
1846 Bash completion
1848 If you use the Bash shell, consider installing the Django bash comple‐
1849 tion script, which lives in extras/django_bash_completion in the Django
1850 source distribution. It enables tab-completion of django-admin and man‐
1851 age.py commands, so you can, for instance...
1852 • Type django-admin.
1854 • Press [TAB] to see all available options.
1856 • Type sql, then [TAB], to see all available options whose names start
1858 with sql.
1859 See How to create custom django-admin commands for how to add custom‐
1861 ized actions.
1862 Black formatting
1864 The Python files created by startproject, startapp, optimizemigration,
1865 makemigrations, and squashmigrations are formatted using the black com‐
1866 mand if it is present on your PATH.
1867 If you have black globally installed, but do not wish it used for the
1869 current project, you can set the PATH explicitly:
1870 PATH=path/to/venv/bin django-admin makemigrations
1872 For commands using stdout you can pipe the output to black if needed:
1874 django-admin inspectdb | black -
1876 django.core.management.call_command(name, *args, **options)
1878 To call a management command from code use call_command.
1880 name the name of the command to call or a command object. Passing the
1882 name is preferred unless the object is required for testing.
1883 *args a list of arguments accepted by the command. Arguments are
1885 passed to the argument parser, so you can use the same style as
1886 you would on the command line. For example, call_com‐
1887 mand('flush', '--verbosity=0').
1888 **options
1890 named options accepted on the command-line. Options are passed
1891 to the command without triggering the argument parser, which
1892 means you'll need to pass the correct type. For example,
1893 call_command('flush', verbosity=0) (zero must be an integer
1894 rather than a string).
1895 Examples:
1897 from django.core import management
1899 from django.core.management.commands import loaddata
1900 management.call_command("flush", verbosity=0, interactive=False)
1902 management.call_command("loaddata", "test_data", verbosity=0)
1903 management.call_command(loaddata.Command(), "test_data", verbosity=0)
1904 Note that command options that take no arguments are passed as keywords
1906 with True or False, as you can see with the interactive option above.
1907 Named arguments can be passed by using either one of the following syn‐
1909 taxes:
1910 # Similar to the command line
1912 management.call_command("dumpdata", "--natural-foreign")
1913 # Named argument similar to the command line minus the initial dashes and
1915 # with internal dashes replaced by underscores
1916 management.call_command("dumpdata", natural_foreign=True)
1917 # `use_natural_foreign_keys` is the option destination variable
1919 management.call_command("dumpdata", use_natural_foreign_keys=True)
1920 Some command options have different names when using call_command() in‐
1922 stead of django-admin or manage.py. For example, django-admin createsu‐
1923 peruser --no-input translates to call_command('createsuperuser', inter‐
1924 active=False). To find what keyword argument name to use for call_com‐
1925 mand(), check the command's source code for the dest argument passed to
1926 parser.add_argument().
1927 Command options which take multiple options are passed a list:
1929 management.call_command("dumpdata", exclude=["contenttypes", "auth"])
1931 The return value of the call_command() function is the same as the re‐
1933 turn value of the handle() method of the command.
1934
1936 Note that you can redirect standard output and error streams as all
1937 commands support the stdout and stderr options. For example, you could
1938 write:
1939 with open("/path/to/command_output", "w") as f:
1941 management.call_command("dumpdata", stdout=f)
1942
1944 Django Software Foundation
1945
1947 Django Software Foundation and contributors
19484.2 April 03, 2023 DJANGO-ADMIN(1)