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 on your path, you can find it in site-pack‐
18 ages/django/bin within your Python installation. Consider symlinking it
19 from some place on your path, such as /usr/local/bin.
20 For Windows users, who do not have symlinking functionality available,
22 you can copy django-admin.exe to a location on your existing path or
23 edit the PATH settings (under Settings - Control Panel - System -
24 Advanced - Environment...) to point to its installed location.
25 Generally, when working on a single Django project, it's easier to use
27 manage.py than django-admin. If you need to switch between multiple
28 Django settings files, use django-admin with DJANGO_SETTINGS_MODULE or
29 the --settings command line option.
30 The command-line examples throughout this document use django-admin to
32 be consistent, but any example can use manage.py or python -m django
33 just as well.
34
36 $ django-admin <command> [options]
37 $ manage.py <command> [options]
38 $ python -m django <command> [options]
39 command should be one of the commands listed in this document.
41 options, which is optional, should be zero or more of the options
42 available for the given command.
43 Getting runtime help
45 django-admin help
46 Run django-admin help to display usage information and a list of the
48 commands provided by each application.
49 Run django-admin help --commands to display a list of all available
51 commands.
52 Run django-admin help <command> to display a description of the given
54 command and a list of its available options.
55 App names
57 Many commands take a list of "app names." An "app name" is the basename
58 of the package containing your models. For example, if your
59 INSTALLED_APPS contains the string 'mysite.blog', the app name is blog.
60 Determining the version
62 django-admin version
63 Run django-admin version to display the current Django version.
65 The output follows the schema described in PEP 440:
67 1.4.dev17026
69 1.4a1
70 1.4
71 Displaying debug output
73 Use --verbosity to specify the amount of notification and debug infor‐
74 mation that django-admin prints to the console.
75
77 check
78 django-admin check [app_label [app_label ...]]
79 Uses the system check framework to inspect the entire Django project
81 for common problems.
82 By default, all apps will be checked. You can check a subset of apps by
84 providing a list of app labels as arguments:
85 django-admin check auth admin myapp
87 If you do not specify any app, all apps will be checked.
89 --tag TAGS, -t TAGS
91 The system check framework performs many different types of checks that
93 are categorized with tags. You can use these tags to restrict the
94 checks performed to just those in a particular category. For example,
95 to perform only models and compatibility checks, run:
96 django-admin check --tag models --tag compatibility
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 DJANGO_SET‐
112 TINGS_MODULE environment variable, or by passing the --settings option:
113 django-admin check --deploy --settings=production_settings
115 Or you could run it directly on a production or staging deployment to
117 verify that the correct settings are in use (omitting --settings). You
118 could even make it part of your integration test suite.
119 --fail-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}
121 Specifies the message level that will cause the command to exit with a
123 non-zero status. Default is ERROR.
124 compilemessages
126 django-admin compilemessages
127 Compiles .po files created by makemessages to .mo files for use with
129 the built-in gettext support. See /topics/i18n/index.
130 --locale LOCALE, -l LOCALE
132 Specifies the locale(s) to process. If not provided, all locales are
134 processed.
135 --exclude EXCLUDE, -x EXCLUDE
137 Specifies the locale(s) to exclude from processing. If not provided, no
139 locales are excluded.
140 --use-fuzzy, -f
142 Includes fuzzy translations into compiled files.
144 Example usage:
146 django-admin compilemessages --locale=pt_BR
148 django-admin compilemessages --locale=pt_BR --locale=fr -f
149 django-admin compilemessages -l pt_BR
150 django-admin compilemessages -l pt_BR -l fr --use-fuzzy
151 django-admin compilemessages --exclude=pt_BR
152 django-admin compilemessages --exclude=pt_BR --exclude=fr
153 django-admin compilemessages -x pt_BR
154 django-admin compilemessages -x pt_BR -x fr
155 --ignore PATTERN, -i PATTERN
157 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
172 information.
173 --database DATABASE
175 Specifies the database in which the cache table(s) will be created.
177 Defaults 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 NOTE:
209 Be aware that not all options set it in the OPTIONS part of your
210 database configuration in DATABASES are passed to the command-line
211 client, e.g. 'isolation_level'.
212 diffsettings
214 django-admin diffsettings
215 Displays differences between the current settings file and Django's
217 default settings (or another settings file specified by --default).
218 Settings that don't appear in the defaults are followed by "###". For
220 example, the default settings don't define ROOT_URLCONF, so ROOT_URL‐
221 CONF is followed by "###" in the output of diffsettings.
222 --all
224 Displays all settings, even if they have Django's default value. Such
226 settings are prefixed by "###".
227 --default MODULE
229 The settings module to compare the current settings against. Leave
231 empty to compare against Django's default settings.
232 --output {hash,unified}
234 Specifies the output format. Available values are hash and unified.
236 hash is the default mode that displays the output that's described
237 above. unified displays the output similar to diff -u. Default set‐
238 tings are prefixed with a minus sign, followed by the changed setting
239 prefixed with a plus sign.
240 dumpdata
242 django-admin dumpdata [app_label[.ModelName] [app_label[.ModelName]
243 ...]]
244 Outputs to standard output all data in the database associated with the
246 named application(s).
247 If no application name is provided, all installed applications will be
249 dumped.
250 The output of dumpdata can be used as input for loaddata.
252 Note that dumpdata uses the default manager on the model for selecting
254 the records to dump. If you're using a custom manager as the default
255 manager and it filters some of the available records, not all of the
256 objects will be dumped.
257 --all, -a
259 Uses Django's base manager, dumping records which might otherwise be
261 filtered or modified by a custom manager.
262 --format FORMAT
264 Specifies the serialization format of the output. Defaults to JSON.
266 Supported formats are listed in serialization-formats.
267 --indent INDENT
269 Specifies the number of indentation spaces to use in the output.
271 Defaults to None which displays all data on single line.
272 --exclude EXCLUDE, -e EXCLUDE
274 Prevents specific applications or models (specified in the form of
276 app_label.ModelName) from being dumped. If you specify a model name,
277 the output will be restricted to that model, rather than the entire
278 application. You can also mix application names and model names.
279 If you want to exclude multiple applications, pass --exclude more than
281 once:
282 django-admin dumpdata --exclude=auth --exclude=contenttypes
284 --database DATABASE
286 Specifies the database from which data will be dumped. Defaults to
288 default.
289 --natural-foreign
291 Uses the natural_key() model method to serialize any foreign key and
293 many-to-many relationship to objects of the type that defines the
294 method. If you're dumping contrib.auth Permission objects or con‐
295 trib.contenttypes ContentType objects, you should probably use this
296 flag. See the natural keys documentation for more details on this and
297 the next option.
298 --natural-primary
300 Omits the primary key in the serialized data of this object since it
302 can be calculated during deserialization.
303 --pks PRIMARY_KEYS
305 Outputs only the objects specified by a comma separated list of primary
307 keys. This is only available when dumping one model. By default, all
308 the records of the model are output.
309 --output OUTPUT, -o OUTPUT
311 Specifies a file to write the serialized data to. By default, the data
313 goes to standard output.
314 When this option is set and --verbosity is greater than 0 (the
316 default), a progress bar is shown in the terminal.
317 flush
319 django-admin flush
320 Removes all data from the database and re-executes any post-synchro‐
322 nization handlers. The table of which migrations have been applied is
323 not cleared.
324 If you would rather start from an empty database and re-run all migra‐
326 tions, you should drop and recreate the database and then run migrate
327 instead.
328 --noinput, --no-input
330 Suppresses all user prompts.
332 --database DATABASE
334 Specifies the database to flush. Defaults to default.
336 inspectdb
338 django-admin inspectdb [table [table ...]]
339 Introspects the database tables in the database pointed-to by the NAME
341 setting and outputs a Django model module (a models.py file) to stan‐
342 dard output.
343 You may choose what tables or views to inspect by passing their names
345 as arguments. If no arguments are provided, models are created for
346 views only if the --include-views option is used. Models for partition
347 tables are created on PostgreSQL if the --include-partitions option is
348 used.
349 Use this if you have a legacy database with which you'd like to use
351 Django. The script will inspect the database and create a model for
352 each table within it.
353 As you might expect, the created models will have an attribute for
355 every field in the table. Note that inspectdb has a few special cases
356 in its field-name output:
357 · If inspectdb cannot map a column's type to a model field type, it'll
359 use TextField and will insert the Python comment 'This field type is
360 a guess.' next to the field in the generated model. The recognized
361 fields may depend on apps listed in INSTALLED_APPS. For example,
362 django.contrib.postgres adds recognition for several PostgreSQL-spe‐
363 cific field types.
364 · If the database column name is a Python reserved word (such as
366 'pass', 'class' or 'for'), inspectdb will append '_field' to the
367 attribute name. For example, if a table has a column 'for', the gen‐
368 erated model will have a field 'for_field', with the db_column
369 attribute set to 'for'. inspectdb will insert the Python comment
370 'Field renamed because it was a Python reserved word.' next to the
371 field.
372 This feature is meant as a shortcut, not as definitive model genera‐
374 tion. After you run it, you'll want to look over the generated models
375 yourself to make customizations. In particular, you'll need to rear‐
376 range models' order, so that models that refer to other models are
377 ordered properly.
378 Django doesn't create database defaults when a default is specified on
380 a model field. Similarly, database defaults aren't translated to model
381 field defaults or detected in any fashion by inspectdb.
382 By default, inspectdb creates unmanaged models. That is, managed =
384 False in the model's Meta class tells Django not to manage each table's
385 creation, modification, and deletion. If you do want to allow Django to
386 manage the table's lifecycle, you'll need to change the managed option
387 to True (or remove it because True is its default value).
388 Database-specific notes
390 Oracle
391 · Models are created for materialized views if --include-views is used.
392 PostgreSQL
394 · Models are created for foreign tables.
395 · Models are created for materialized views if --include-views is used.
397 · Models are created for partition tables if --include-partitions is
399 used.
400 Support for foreign tables and materialized views was added.
402 --database DATABASE
405 Specifies the database to introspect. Defaults to default.
407 --include-partitions
409 If this option is provided, models are also created for partitions.
413 Only support for PostgreSQL is implemented.
415 --include-views
417 If this option is provided, models are also created for database views.
419 loaddata
421 django-admin loaddata fixture [fixture ...]
422 Searches for and loads the contents of the named fixture into the data‐
424 base.
425 --database DATABASE
427 Specifies the database into which the data will be loaded. Defaults to
429 default.
430 --ignorenonexistent, -i
432 Ignores fields and models that may have been removed since the fixture
434 was originally generated.
435 --app APP_LABEL
437 Specifies a single app to look for fixtures in rather than looking in
439 all apps.
440 --format FORMAT
442 Specifies the serialization format (e.g., json or xml) for fixtures
444 read from stdin.
445 --exclude EXCLUDE, -e EXCLUDE
447 Excludes loading the fixtures from the given applications and/or models
449 (in the form of app_label or app_label.ModelName). Use the option mul‐
450 tiple times to exclude more than one app or model.
451 What's a fixture ?
453 A fixture is a collection of files that contain the serialized contents
454 of the database. Each fixture has a unique name, and the files that
455 comprise the fixture can be distributed over multiple directories, in
456 multiple applications.
457 Django will search in three locations for fixtures:
459 1. In the fixtures directory of every installed application
461 2. In any directory named in the FIXTURE_DIRS setting
463 3. In the literal path named by the fixture
465 Django will load any and all fixtures it finds in these locations that
467 match the provided fixture names.
468 If the named fixture has a file extension, only fixtures of that type
470 will be loaded. For example:
471 django-admin loaddata mydata.json
473 would only load JSON fixtures called mydata. The fixture extension must
475 correspond to the registered name of a serializer (e.g., json or xml).
476 If you omit the extensions, Django will search all available fixture
478 types for a matching fixture. For example:
479 django-admin loaddata mydata
481 would look for any fixture of any fixture type called mydata. If a fix‐
483 ture directory contained mydata.json, that fixture would be loaded as a
484 JSON fixture.
485 The fixtures that are named can include directory components. These
487 directories will be included in the search path. For example:
488 django-admin loaddata foo/bar/mydata.json
490 would search <app_label>/fixtures/foo/bar/mydata.json for each
492 installed application, <dirname>/foo/bar/mydata.json for each direc‐
493 tory in FIXTURE_DIRS, and the literal path foo/bar/mydata.json.
494 When fixture files are processed, the data is saved to the database as
496 is. Model defined save() methods are not called, and any pre_save or
497 post_save signals will be called with raw=True since the instance only
498 contains attributes that are local to the model. You may, for example,
499 want to disable handlers that access related fields that aren't present
500 during fixture loading and would otherwise raise an exception:
501 from django.db.models.signals import post_save
503 from .models import MyModel
504 def my_handler(**kwargs):
506 # disable the handler during fixture loading
507 if kwargs['raw']:
508 return
509 ...
510 post_save.connect(my_handler, sender=MyModel)
512 You could also write a decorator to encapsulate this logic:
514 from functools import wraps
516 def disable_for_loaddata(signal_handler):
518 """
519 Decorator that turns off signal handlers when loading fixture data.
520 """
521 @wraps(signal_handler)
522 def wrapper(*args, **kwargs):
523 if kwargs['raw']:
524 return
525 signal_handler(*args, **kwargs)
526 return wrapper
527 @disable_for_loaddata
529 def my_handler(**kwargs):
530 ...
531 Just be aware that this logic will disable the signals whenever fix‐
533 tures are deserialized, not just during loaddata.
534 Note that the order in which fixture files are processed is undefined.
536 However, all fixture data is installed as a single transaction, so data
537 in one fixture can reference data in another fixture. If the database
538 backend supports row-level constraints, these constraints will be
539 checked at the end of the transaction.
540 The dumpdata command can be used to generate input for loaddata.
542 Compressed fixtures
544 Fixtures may be compressed in zip, gz, or bz2 format. For example:
545 django-admin loaddata mydata.json
547 would look for any of mydata.json, mydata.json.zip, mydata.json.gz, or
549 mydata.json.bz2. The first file contained within a zip-compressed ar‐
550 chive is used.
551 Note that if two fixtures with the same name but different fixture type
553 are discovered (for example, if mydata.json and mydata.xml.gz were
554 found in the same fixture directory), fixture installation will be
555 aborted, and any data installed in the call to loaddata will be removed
556 from the database.
557 MySQL with MyISAM and fixtures
559 The MyISAM storage engine of MySQL doesn't support transac‐
561 tions or constraints, so if you use MyISAM, you won't get
562 validation of fixture data, or a rollback if multiple trans‐
563 action files are found.
564 Database-specific fixtures
566 If you're in a multi-database setup, you might have fixture data that
567 you want to load onto one database, but not onto another. In this situ‐
568 ation, you can add a database identifier into the names of your fix‐
569 tures.
570 For example, if your DATABASES setting has a 'master' database defined,
572 name the fixture mydata.master.json or mydata.master.json.gz and the
573 fixture will only be loaded when you specify you want to load data into
574 the master database.
575 Loading fixtures from stdin
577 You can use a dash as the fixture name to load input from sys.stdin.
578 For example:
579 django-admin loaddata --format=json -
581 When reading from stdin, the --format option is required to specify the
583 serialization format of the input (e.g., json or xml).
584 Loading from stdin is useful with standard input and output redirec‐
586 tions. For example:
587 django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -
589 makemessages
591 django-admin makemessages
592 Runs over the entire source tree of the current directory and pulls out
594 all strings marked for translation. It creates (or updates) a message
595 file in the conf/locale (in the Django tree) or locale (for project and
596 application) directory. After making changes to the messages files you
597 need to compile them with compilemessages for use with the builtin get‐
598 text support. See the i18n documentation for details.
599 This command doesn't require configured settings. However, when set‐
601 tings aren't configured, the command can't ignore the MEDIA_ROOT and
602 STATIC_ROOT directories or include LOCALE_PATHS.
603 --all, -a
605 Updates the message files for all available languages.
607 --extension EXTENSIONS, -e EXTENSIONS
609 Specifies a list of file extensions to examine (default: html, txt, py
611 or js if --domain is js).
612 Example usage:
614 django-admin makemessages --locale=de --extension xhtml
616 Separate multiple extensions with commas or use -e or --extension mul‐
618 tiple times:
619 django-admin makemessages --locale=de --extension=html,txt --extension xml
621 --locale LOCALE, -l LOCALE
623 Specifies the locale(s) to process.
625 --exclude EXCLUDE, -x EXCLUDE
627 Specifies the locale(s) to exclude from processing. If not provided, no
629 locales are excluded.
630 Example usage:
632 django-admin makemessages --locale=pt_BR
634 django-admin makemessages --locale=pt_BR --locale=fr
635 django-admin makemessages -l pt_BR
636 django-admin makemessages -l pt_BR -l fr
637 django-admin makemessages --exclude=pt_BR
638 django-admin makemessages --exclude=pt_BR --exclude=fr
639 django-admin makemessages -x pt_BR
640 django-admin makemessages -x pt_BR -x fr
641 --domain DOMAIN, -d DOMAIN
643 Specifies the domain of the messages files. Supported options are:
645 · django for all *.py, *.html and *.txt files (default)
647 · djangojs for *.js files
649 --symlinks, -s
651 Follows symlinks to directories when looking for new translation
653 strings.
654 Example usage:
656 django-admin makemessages --locale=de --symlinks
658 --ignore PATTERN, -i PATTERN
660 Ignores files or directories matching the given glob-style pattern. Use
662 multiple times to ignore more.
663 These patterns are used by default: 'CVS', '.*', '*~', '*.pyc'.
665 Example usage:
667 django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html
669 --no-default-ignore
671 Disables the default values of --ignore.
673 --no-wrap
675 Disables breaking long message lines into several lines in language
677 files.
678 --no-location
680 Suppresses writing '#: filename:line’ comment lines in language files.
682 Using this option makes it harder for technically skilled translators
683 to understand each message's context.
684 --add-location [{full,file,never}]
686 Controls #: filename:line comment lines in language files. If the
688 option is:
689 · full (the default if not given): the lines include both file name and
691 line number.
692 · file: the line number is omitted.
694 · never: the lines are suppressed (same as --no-location).
696 Requires gettext 0.19 or newer.
698 --keep-pot
700 Prevents deleting the temporary .pot files generated before creating
702 the .po file. This is useful for debugging errors which may prevent the
703 final language files from being created.
704 SEE ALSO:
706 See customizing-makemessages for instructions on how to customize
707 the keywords that makemessages passes to xgettext.
708 makemigrations
710 django-admin makemigrations [app_label [app_label ...]]
711 Creates new migrations based on the changes detected to your models.
713 Migrations, their relationship with apps and more are covered in depth
714 in the migrations documentation.
715 Providing one or more app names as arguments will limit the migrations
717 created to the app(s) specified and any dependencies needed (the table
718 at the other end of a ForeignKey, for example).
719 To add migrations to an app that doesn't have a migrations directory,
721 run makemigrations with the app's app_label.
722 --noinput, --no-input
724 Suppresses all user prompts. If a suppressed prompt cannot be resolved
726 automatically, the command will exit with error code 3.
727 --empty
729 Outputs an empty migration for the specified apps, for manual editing.
731 This is for advanced users and should not be used unless you are famil‐
732 iar with the migration format, migration operations, and the dependen‐
733 cies between your migrations.
734 --dry-run
736 Shows what migrations would be made without actually writing any migra‐
738 tions files to disk. Using this option along with --verbosity 3 will
739 also show the complete migrations files that would be written.
740 --merge
742 Enables fixing of migration conflicts.
744 --name NAME, -n NAME
746 Allows naming the generated migration(s) instead of using a generated
748 name. The name must be a valid Python identifier.
749 --no-header
751 Generate migration files without Django version and timestamp header.
755 --check
757 Makes makemigrations exit with a non-zero status when model changes
759 without migrations are detected.
760 migrate
762 django-admin migrate [app_label] [migration_name]
763 Synchronizes the database state with the current set of models and
765 migrations. Migrations, their relationship with apps and more are cov‐
766 ered in depth in the migrations documentation.
767 The behavior of this command changes depending on the arguments pro‐
769 vided:
770 · No arguments: All apps have all of their migrations run.
772 · <app_label>: The specified app has its migrations run, up to the most
774 recent migration. This may involve running other apps' migrations
775 too, due to dependencies.
776 · <app_label> <migrationname>: Brings the database schema to a state
778 where the named migration is applied, but no later migrations in the
779 same app are applied. This may involve unapplying migrations if you
780 have previously migrated past the named migration. You can use a pre‐
781 fix of the migration name, e.g. 0001, as long as it's unique for the
782 given app name. Use the name zero to migrate all the way back i.e. to
783 revert all applied migrations for an app.
784 WARNING:
786 When unapplying migrations, all dependent migrations will also be
787 unapplied, regardless of <app_label>. You can use --plan to check
788 which migrations will be unapplied.
789 --database DATABASE
791 Specifies the database to migrate. Defaults to default.
793 --fake
795 Marks the migrations up to the target one (following the rules above)
797 as applied, but without actually running the SQL to change your data‐
798 base schema.
799 This is intended for advanced users to manipulate the current migration
801 state directly if they're manually applying changes; be warned that
802 using --fake runs the risk of putting the migration state table into a
803 state where manual recovery will be needed to make migrations run cor‐
804 rectly.
805 --fake-initial
807 Allows Django to skip an app's initial migration if all database tables
809 with the names of all models created by all CreateModel operations in
810 that migration already exist. This option is intended for use when
811 first running migrations against a database that preexisted the use of
812 migrations. This option does not, however, check for matching database
813 schema beyond matching table names and so is only safe to use if you
814 are confident that your existing schema matches what is recorded in
815 your initial migration.
816 --plan
818 Shows the migration operations that will be performed for the given
822 migrate command.
823 --run-syncdb
825 Allows creating tables for apps without migrations. While this isn't
827 recommended, the migrations framework is sometimes too slow on large
828 projects with hundreds of models.
829 --noinput, --no-input
831 Suppresses all user prompts. An example prompt is asking about removing
833 stale content types.
834 runserver
836 django-admin runserver [addrport]
837 Starts a lightweight development Web server on the local machine. By
839 default, the server runs on port 8000 on the IP address 127.0.0.1. You
840 can pass in an IP address and port number explicitly.
841 If you run this script as a user with normal privileges (recommended),
843 you might not have access to start a port on a low port number. Low
844 port numbers are reserved for the superuser (root).
845 This server uses the WSGI application object specified by the
847 WSGI_APPLICATION setting.
848 DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through
850 security audits or performance tests. (And that's how it's gonna stay.
851 We're in the business of making Web frameworks, not Web servers, so
852 improving this server to be able to handle a production environment is
853 outside the scope of Django.)
854 The development server automatically reloads Python code for each
856 request, as needed. You don't need to restart the server for code
857 changes to take effect. However, some actions like adding files don't
858 trigger a restart, so you'll have to restart the server in these cases.
859 If you're using Linux or MacOS and install both pywatchman and the
861 Watchman service, kernel signals will be used to autoreload the server
862 (rather than polling file modification timestamps each second). This
863 offers better performance on large projects, reduced response time
864 after code changes, more robust change detection, and a reduction in
865 power usage. Django supports pywatchman 1.2.0 and higher.
866 Large directories with many files may cause performance issues
868 When using Watchman with a project that includes large
870 non-Python directories like node_modules, it's advisable to
871 ignore this directory for optimal performance. See the
872 watchman documentation for information on how to do this.
873 Watchman timeout
875 The default timeout of Watchman client is 5 seconds. You can
877 change it by setting the DJANGO_WATCHMAN_TIMEOUT environment
878 variable.
879 Watchman support replaced support for pyinotify.
881 When you start the server, and each time you change Python code while
884 the server is running, the system check framework will check your
885 entire Django project for some common errors (see the check command).
886 If any errors are found, they will be printed to standard output.
887 You can run as many concurrent servers as you want, as long as they're
889 on separate ports by executing django-admin runserver more than once.
890 Note that the default IP address, 127.0.0.1, is not accessible from
892 other machines on your network. To make your development server view‐
893 able to other machines on the network, use its own IP address (e.g.
894 192.168.2.1) or 0.0.0.0 or :: (with IPv6 enabled).
895 You can provide an IPv6 address surrounded by brackets (e.g.
897 [200a::1]:8000). This will automatically enable IPv6 support.
898 A hostname containing ASCII-only characters can also be used.
900 If the staticfiles contrib app is enabled (default in new projects) the
902 runserver command will be overridden with its own runserver command.
903 Logging of each request and response of the server is sent to the
905 django-server-logger logger.
906 --noreload
908 Disables the auto-reloader. This means any Python code changes you make
910 while the server is running will not take effect if the particular
911 Python modules have already been loaded into memory.
912 --nothreading
914 Disables use of threading in the development server. The server is mul‐
916 tithreaded by default.
917 --ipv6, -6
919 Uses IPv6 for the development server. This changes the default IP
921 address from 127.0.0.1 to ::1.
922 Examples of using different ports and addresses
924 Port 8000 on IP address 127.0.0.1:
925 django-admin runserver
927 Port 8000 on IP address 1.2.3.4:
929 django-admin runserver 1.2.3.4:8000
931 Port 7000 on IP address 127.0.0.1:
933 django-admin runserver 7000
935 Port 7000 on IP address 1.2.3.4:
937 django-admin runserver 1.2.3.4:7000
939 Port 8000 on IPv6 address ::1:
941 django-admin runserver -6
943 Port 7000 on IPv6 address ::1:
945 django-admin runserver -6 7000
947 Port 7000 on IPv6 address 2001:0db8:1234:5678::9:
949 django-admin runserver [2001:0db8:1234:5678::9]:7000
951 Port 8000 on IPv4 address of host localhost:
953 django-admin runserver localhost:8000
955 Port 8000 on IPv6 address of host localhost:
957 django-admin runserver -6 localhost:8000
959 Serving static files with the development server
961 By default, the development server doesn't serve any static files for
962 your site (such as CSS files, images, things under MEDIA_URL and so
963 forth). If you want to configure Django to serve static media, read
964 /howto/static-files/index.
965 sendtestemail
967 django-admin sendtestemail [email [email ...]]
968 Sends a test email (to confirm email sending through Django is working)
970 to the recipient(s) specified. For example:
971 django-admin sendtestemail foo@example.com bar@example.com
973 There are a couple of options, and you may use any combination of them
975 together:
976 --managers
978 Mails the email addresses specified in MANAGERS using mail_managers().
980 --admins
982 Mails the email addresses specified in ADMINS using mail_admins().
984 shell
986 django-admin shell
987 Starts the Python interactive interpreter.
989 --interface {ipython,bpython,python}, -i {ipython,bpython,python}
991 Specifies the shell to use. By default, Django will use IPython or
993 bpython if either is installed. If both are installed, specify which
994 one you want like so:
995 IPython:
997 django-admin shell -i ipython
999 bpython:
1001 django-admin shell -i bpython
1003 If you have a "rich" shell installed but want to force use of the
1005 "plain" Python interpreter, use python as the interface name, like so:
1006 django-admin shell -i python
1008 --nostartup
1010 Disables reading the startup script for the "plain" Python interpreter.
1012 By default, the script pointed to by the PYTHONSTARTUP environment
1013 variable or the ~/.pythonrc.py script is read.
1014 --command COMMAND, -c COMMAND
1016 Lets you pass a command as a string to execute it as Django, like so:
1018 django-admin shell --command="import django; print(django.__version__)"
1020 You can also pass code in on standard input to execute it. For example:
1022 $ django-admin shell <<EOF
1024 > import django
1025 > print(django.__version__)
1026 > EOF
1027 On Windows, the REPL is output due to implementation limits of
1029 select.select() on that platform.
1030 showmigrations
1032 django-admin showmigrations [app_label [app_label ...]]
1033 Shows all migrations in a project. You can choose from one of two for‐
1035 mats:
1036 --list, -l
1038 Lists all of the apps Django knows about, the migrations available for
1040 each app, and whether or not each migration is applied (marked by an
1041 [X] next to the migration name). For a --verbosity of 2 and above, the
1042 applied datetimes are also shown.
1043 Apps without migrations are also listed, but have (no migrations)
1045 printed under them.
1046 This is the default output format.
1048 Output of the applied datetimes at verbosity 2 and above was added.
1050 --plan, -p
1053 Shows the migration plan Django will follow to apply migrations. Like
1055 --list, applied migrations are marked by an [X]. For a --verbosity of 2
1056 and above, all dependencies of a migration will also be shown.
1057 app_labels arguments limit the output, however, dependencies of pro‐
1059 vided apps may also be included.
1060 --database DATABASE
1062 Specifies the database to examine. Defaults to default.
1064 sqlflush
1066 django-admin sqlflush
1067 Prints the SQL statements that would be executed for the flush command.
1069 --database DATABASE
1071 Specifies the database for which to print the SQL. Defaults to default.
1073 sqlmigrate
1075 django-admin sqlmigrate app_label migration_name
1076 Prints the SQL for the named migration. This requires an active data‐
1078 base connection, which it will use to resolve constraint names; this
1079 means you must generate the SQL against a copy of the database you wish
1080 to later apply it on.
1081 Note that sqlmigrate doesn't colorize its output.
1083 --backwards
1085 Generates the SQL for unapplying the migration. By default, the SQL
1087 created is for running the migration in the forwards direction.
1088 --database DATABASE
1090 Specifies the database for which to generate the SQL. Defaults to
1092 default.
1093 sqlsequencereset
1095 django-admin sqlsequencereset app_label [app_label ...]
1096 Prints the SQL statements for resetting sequences for the given app
1098 name(s).
1099 Sequences are indexes used by some database engines to track the next
1101 available number for automatically incremented fields.
1102 Use this command to generate SQL which will fix cases where a sequence
1104 is out of sync with its automatically incremented field data.
1105 --database DATABASE
1107 Specifies the database for which to print the SQL. Defaults to default.
1109 squashmigrations
1111 django-admin squashmigrations app_label [start_migration_name] migra‐
1112 tion_name
1113 Squashes the migrations for app_label up to and including migra‐
1115 tion_name down into fewer migrations, if possible. The resulting
1116 squashed migrations can live alongside the unsquashed ones safely. For
1117 more information, please read migration-squashing.
1118 When start_migration_name is given, Django will only include migrations
1120 starting from and including this migration. This helps to mitigate the
1121 squashing limitation of RunPython and django.db.migrations.opera‐
1122 tions.RunSQL migration operations.
1123 --no-optimize
1125 Disables the optimizer when generating a squashed migration. By
1127 default, Django will try to optimize the operations in your migrations
1128 to reduce the size of the resulting file. Use this option if this
1129 process is failing or creating incorrect migrations, though please also
1130 file a Django bug report about the behavior, as optimization is meant
1131 to be safe.
1132 --noinput, --no-input
1134 Suppresses all user prompts.
1136 --squashed-name SQUASHED_NAME
1138 Sets the name of the squashed migration. When omitted, the name is
1140 based on the first and last migration, with _squashed_ in between.
1141 --no-header
1143 Generate squashed migration file without Django version and timestamp
1147 header.
1148 startapp
1150 django-admin startapp name [directory]
1151 Creates a Django app directory structure for the given app name in the
1153 current directory or the given destination.
1154 By default, the new directory contains a models.py file and other app
1156 template files. If only the app name is given, the app directory will
1157 be created in the current working directory.
1158 If the optional destination is provided, Django will use that existing
1160 directory rather than creating a new one. You can use '.' to denote the
1161 current working directory.
1162 For example:
1164 django-admin startapp myapp /Users/jezdez/Code/myapp
1166 --template TEMPLATE
1168 Provides the path to a directory with a custom app template file, or a
1170 path to an uncompressed archive (.tar) or a compressed archive
1171 (.tar.gz, .tar.bz2, .tar.xz, .tar.lzma, .tgz, .tbz2, .txz, .tlz, .zip)
1172 containing the app template files.
1173 For example, this would look for an app template in the given directory
1175 when creating the myapp app:
1176 django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp
1178 Django will also accept URLs (http, https, ftp) to compressed archives
1180 with the app template files, downloading and extracting them on the
1181 fly.
1182 For example, taking advantage of GitHub's feature to expose reposito‐
1184 ries as zip files, you can use a URL like:
1185 django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip myapp
1187 Support for XZ archives (.tar.xz, .txz) and LZMA archives (.tar.lzma,
1189 .tlz) was added.
1190 --extension EXTENSIONS, -e EXTENSIONS
1193 Specifies which file extensions in the app template should be rendered
1195 with the template engine. Defaults to py.
1196 --name FILES, -n FILES
1198 Specifies which files in the app template (in addition to those match‐
1200 ing --extension) should be rendered with the template engine. Defaults
1201 to an empty list.
1202 The template context used for all matching files is:
1204 · Any option passed to the startapp command (among the command's sup‐
1206 ported options)
1207 · app_name -- the app name as passed to the command
1209 · app_directory -- the full path of the newly created app
1211 · camel_case_app_name -- the app name in camel case format
1213 · docs_version -- the version of the documentation: 'dev' or '1.x'
1215 · django_version -- the version of Django, e.g. '2.0.3'
1217 WARNING:
1219 When the app template files are rendered with the Django template
1220 engine (by default all *.py files), Django will also replace all
1221 stray template variables contained. For example, if one of the
1222 Python files contains a docstring explaining a particular feature
1223 related to template rendering, it might result in an incorrect exam‐
1224 ple.
1225 To work around this problem, you can use the templatetag template
1227 tag to "escape" the various parts of the template syntax.
1228 In addition, to allow Python template files that contain Django tem‐
1230 plate language syntax while also preventing packaging systems from
1231 trying to byte-compile invalid *.py files, template files ending
1232 with .py-tpl will be renamed to .py.
1233 startproject
1235 django-admin startproject name [directory]
1236 Creates a Django project directory structure for the given project name
1238 in the current directory or the given destination.
1239 By default, the new directory contains manage.py and a project package
1241 (containing a settings.py and other files).
1242 If only the project name is given, both the project directory and
1244 project package will be named <projectname> and the project directory
1245 will be created in the current working directory.
1246 If the optional destination is provided, Django will use that existing
1248 directory as the project directory, and create manage.py and the
1249 project package within it. Use '.' to denote the current working direc‐
1250 tory.
1251 For example:
1253 django-admin startproject myproject /Users/jezdez/Code/myproject_repo
1255 --template TEMPLATE
1257 Specifies a directory, file path, or URL of a custom project template.
1259 See the startapp --template documentation for examples and usage.
1260 --extension EXTENSIONS, -e EXTENSIONS
1262 Specifies which file extensions in the project template should be ren‐
1264 dered with the template engine. Defaults to py.
1265 --name FILES, -n FILES
1267 Specifies which files in the project template (in addition to those
1269 matching --extension) should be rendered with the template engine.
1270 Defaults to an empty list.
1271 The template context used is:
1273 · Any option passed to the startproject command (among the command's
1275 supported options)
1276 · project_name -- the project name as passed to the command
1278 · project_directory -- the full path of the newly created project
1280 · secret_key -- a random key for the SECRET_KEY setting
1282 · docs_version -- the version of the documentation: 'dev' or '1.x'
1284 · django_version -- the version of Django, e.g. '2.0.3'
1286 Please also see the rendering warning as mentioned for startapp.
1288 test
1290 django-admin test [test_label [test_label ...]]
1291 Runs tests for all installed apps. See /topics/testing/index for more
1293 information.
1294 --failfast
1296 Stops running tests and reports the failure immediately after a test
1298 fails.
1299 --testrunner TESTRUNNER
1301 Controls the test runner class that is used to execute tests. This
1303 value overrides the value provided by the TEST_RUNNER setting.
1304 --noinput, --no-input
1306 Suppresses all user prompts. A typical prompt is a warning about delet‐
1308 ing an existing test database.
1309 Test runner options
1311 The test command receives options on behalf of the specified
1312 --testrunner. These are the options of the default test runner: Discov‐
1313 erRunner.
1314 --keepdb
1316 Preserves the test database between test runs. This has the advantage
1318 of skipping both the create and destroy actions which can greatly
1319 decrease the time to run tests, especially those in a large test suite.
1320 If the test database does not exist, it will be created on the first
1321 run and then preserved for each subsequent run. Any unapplied migra‐
1322 tions will also be applied to the test database before running the test
1323 suite.
1324 --reverse, -r
1326 Sorts test cases in the opposite execution order. This may help in
1328 debugging the side effects of tests that aren't properly isolated.
1329 Grouping by test class is preserved when using this option.
1330 --debug-mode
1332 Sets the DEBUG setting to True prior to running tests. This may help
1334 troubleshoot test failures.
1335 --debug-sql, -d
1337 Enables SQL logging for failing tests. If --verbosity is 2, then
1339 queries in passing tests are also output.
1340 --parallel [N]
1342 Runs tests in separate parallel processes. Since modern processors have
1344 multiple cores, this allows running tests significantly faster.
1345 By default --parallel runs one process per core according to
1347 multiprocessing.cpu_count(). You can adjust the number of processes
1348 either by providing it as the option's value, e.g. --parallel=4, or by
1349 setting the DJANGO_TEST_PROCESSES environment variable.
1350 Django distributes test cases — unittest.TestCase subclasses — to sub‐
1352 processes. If there are fewer test cases than configured processes,
1353 Django will reduce the number of processes accordingly.
1354 Each process gets its own database. You must ensure that different test
1356 cases don't access the same resources. For instance, test cases that
1357 touch the filesystem should create a temporary directory for their own
1358 use.
1359 NOTE:
1361 If you have test classes that cannot be run in parallel, you can use
1362 SerializeMixin to run them sequentially. See Enforce running test
1363 classes sequentially.
1364 This option requires the third-party tblib package to display trace‐
1366 backs correctly:
1367 $ python -m pip install tblib
1369 This feature isn't available on Windows. It doesn't work with the Ora‐
1371 cle database backend either.
1372 If you want to use pdb while debugging tests, you must disable parallel
1374 execution (--parallel=1). You'll see something like bdb.BdbQuit if you
1375 don't.
1376 WARNING:
1378 When test parallelization is enabled and a test fails, Django may be
1379 unable to display the exception traceback. This can make debugging
1380 difficult. If you encounter this problem, run the affected test
1381 without parallelization to see the traceback of the failure.
1382 This is a known limitation. It arises from the need to serialize
1384 objects in order to exchange them between processes. See What can be
1385 pickled and unpickled? for details.
1386 --tag TAGS
1388 Runs only tests marked with the specified tags. May be specified mul‐
1390 tiple times and combined with test --exclude-tag.
1391 --exclude-tag EXCLUDE_TAGS
1393 Excludes tests marked with the specified tags. May be specified multi‐
1395 ple times and combined with test --tag.
1396 -k TEST_NAME_PATTERNS
1398 Runs test methods and classes matching test name patterns, in the same
1402 way as unittest's -k option. Can be specified multiple times.
1403 Python 3.7 and later
1405 This feature is only available for Python 3.7 and later.
1407 --pdb
1409 Spawns a pdb debugger at each test error or failure. If you have it
1413 installed, ipdb is used instead.
1414 testserver
1416 django-admin testserver [fixture [fixture ...]]
1417 Runs a Django development server (as in runserver) using data from the
1419 given fixture(s).
1420 For example, this command:
1422 django-admin testserver mydata.json
1424 ...would perform the following steps:
1426 1. Create a test database, as described in the-test-database.
1428 2. Populate the test database with fixture data from the given fix‐
1430 tures. (For more on fixtures, see the documentation for loaddata
1431 above.)
1432 3. Runs the Django development server (as in runserver), pointed at
1434 this newly created test database instead of your production data‐
1435 base.
1436 This is useful in a number of ways:
1438 · When you're writing unit tests of how your views act with certain
1440 fixture data, you can use testserver to interact with the views in a
1441 Web browser, manually.
1442 · Let's say you're developing your Django application and have a "pris‐
1444 tine" copy of a database that you'd like to interact with. You can
1445 dump your database to a fixture (using the dumpdata command,
1446 explained above), then use testserver to run your Web application
1447 with that data. With this arrangement, you have the flexibility of
1448 messing up your data in any way, knowing that whatever data changes
1449 you're making are only being made to a test database.
1450 Note that this server does not automatically detect changes to your
1452 Python source code (as runserver does). It does, however, detect
1453 changes to templates.
1454 --addrport ADDRPORT
1456 Specifies a different port, or IP address and port, from the default of
1458 127.0.0.1:8000. This value follows exactly the same format and serves
1459 exactly the same function as the argument to the runserver command.
1460 Examples:
1462 To run the test server on port 7000 with fixture1 and fixture2:
1464 django-admin testserver --addrport 7000 fixture1 fixture2
1466 django-admin testserver fixture1 fixture2 --addrport 7000
1467 (The above statements are equivalent. We include both of them to demon‐
1469 strate that it doesn't matter whether the options come before or after
1470 the fixture arguments.)
1471 To run on 1.2.3.4:7000 with a test fixture:
1473 django-admin testserver --addrport 1.2.3.4:7000 test
1475 --noinput, --no-input
1477 Suppresses all user prompts. A typical prompt is a warning about delet‐
1479 ing an existing test database.
1480
1482 Some commands are only available when the django.contrib application
1483 that implements them has been enabled. This section describes them
1484 grouped by their application.
1485 django.contrib.auth
1487 changepassword
1488 django-admin changepassword [<username>]
1489 This command is only available if Django's authentication system
1491 (django.contrib.auth) is installed.
1492 Allows changing a user's password. It prompts you to enter a new pass‐
1494 word twice for the given user. If the entries are identical, this imme‐
1495 diately becomes the new password. If you do not supply a user, the com‐
1496 mand will attempt to change the password whose username matches the
1497 current user.
1498 --database DATABASE
1500 Specifies the database to query for the user. Defaults to default.
1502 Example usage:
1504 django-admin changepassword ringo
1506 createsuperuser
1508 django-admin createsuperuser
1509 This command is only available if Django's authentication system
1511 (django.contrib.auth) is installed.
1512 Creates a superuser account (a user who has all permissions). This is
1514 useful if you need to create an initial superuser account or if you
1515 need to programmatically generate superuser accounts for your site(s).
1516 When run interactively, this command will prompt for a password for the
1518 new superuser account. When run non-interactively, you can provide a
1519 password by setting the DJANGO_SUPERUSER_PASSWORD environment variable.
1520 Otherwise, no password will be set, and the superuser account will not
1521 be able to log in until a password has been manually set for it.
1522 In non-interactive mode, the USERNAME_FIELD and required fields (listed
1524 in REQUIRED_FIELDS) fall back to DJANGO_SUPERUSER_<upper‐
1525 case_field_name> environment variables, unless they are overridden by a
1526 command line argument. For example, to provide an email field, you can
1527 use DJANGO_SUPERUSER_EMAIL environment variable.
1528 Support for using DJANGO_SUPERUSER_PASSWORD and DJANGO_SUPE‐
1530 RUSER_<uppercase_field_name> environment variables was added.
1531 --noinput, --no-input
1534 Suppresses all user prompts. If a suppressed prompt cannot be resolved
1536 automatically, the command will exit with error code 1.
1537 --username USERNAME
1539 --email EMAIL
1541 The username and email address for the new account can be supplied by
1543 using the --username and --email arguments on the command line. If
1544 either of those is not supplied, createsuperuser will prompt for it
1545 when running interactively.
1546 --database DATABASE
1548 Specifies the database into which the superuser object will be saved.
1550 You can subclass the management command and override get_input_data()
1552 if you want to customize data input and validation. Consult the source
1553 code for details on the existing implementation and the method's param‐
1554 eters. For example, it could be useful if you have a ForeignKey in
1555 REQUIRED_FIELDS and want to allow creating an instance instead of
1556 entering the primary key of an existing instance.
1557 django.contrib.contenttypes
1559 remove_stale_contenttypes
1560 django-admin remove_stale_contenttypes
1561 This command is only available if Django's contenttypes app
1563 (django.contrib.contenttypes) is installed.
1564 Deletes stale content types (from deleted models) in your database. Any
1566 objects that depend on the deleted content types will also be deleted.
1567 A list of deleted objects will be displayed before you confirm it's
1568 okay to proceed with the deletion.
1569 --database DATABASE
1571 Specifies the database to use. Defaults to default.
1573 django.contrib.gis
1575 ogrinspect
1576 This command is only available if GeoDjango (django.contrib.gis) is
1577 installed.
1578 Please refer to its description in the GeoDjango documentation.
1580 django.contrib.sessions
1582 clearsessions
1583 django-admin clearsessions
1584 Can be run as a cron job or directly to clean out expired sessions.
1586 django.contrib.sitemaps
1588 ping_google
1589 This command is only available if the Sitemaps framework (django.con‐
1590 trib.sitemaps) is installed.
1591 Please refer to its description in the Sitemaps documentation.
1593 django.contrib.staticfiles
1595 collectstatic
1596 This command is only available if the static files application
1597 (django.contrib.staticfiles) is installed.
1598 Please refer to its description in the staticfiles documentation.
1600 findstatic
1602 This command is only available if the static files application
1603 (django.contrib.staticfiles) is installed.
1604 Please refer to its description in the staticfiles documentation.
1606
1608 Although some commands may allow their own custom options, every com‐
1609 mand allows for the following options:
1610 --pythonpath PYTHONPATH
1612 Adds the given filesystem path to the Python import search path. If
1614 this isn't provided, django-admin will use the PYTHONPATH environment
1615 variable.
1616 This option is unnecessary in manage.py, because it takes care of set‐
1618 ting the Python path for you.
1619 Example usage:
1621 django-admin migrate --pythonpath='/home/djangoprojects/myproject'
1623 --settings SETTINGS
1625 Specifies the settings module to use. The settings module should be in
1627 Python package syntax, e.g. mysite.settings. If this isn't provided,
1628 django-admin will use the DJANGO_SETTINGS_MODULE environment variable.
1629 This option is unnecessary in manage.py, because it uses settings.py
1631 from the current project by default.
1632 Example usage:
1634 django-admin migrate --settings=mysite.settings
1636 --traceback
1638 Displays a full stack trace when a CommandError is raised. By default,
1640 django-admin will show an error message when a CommandError occurs and
1641 a full stack trace for any other exception.
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 Example usage:
1661 django-admin migrate --verbosity 2
1663 --no-color
1665 Disables colorized command output. Some commands format their output
1667 to be colorized. For example, errors will be printed to the console in
1668 red and SQL statements will be syntax highlighted.
1669 Example usage:
1671 django-admin runserver --no-color
1673 --force-color
1675 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
1687 is only available if the requires_system_checks command attribute is
1688 set to True.
1689 Example usage:
1691 django-admin migrate --skip-checks
1693
1695 Syntax coloring
1696 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 Under Windows, the native console doesn't support ANSI escape sequences
1702 so by default there is no color output. But you can install the ANSICON
1703 third-party tool, the Django commands will detect its presence and will
1704 make use of its services to color output just like on Unix-based plat‐
1705 forms.
1706 The colors used for syntax highlighting can be customized. Django ships
1708 with three color palettes:
1709 · dark, suited to terminals that show white text on a black background.
1711 This is the default palette.
1712 · light, suited to terminals that show black text on a white back‐
1714 ground.
1715 · nocolor, which disables syntax highlighting.
1717 You select a palette by setting a DJANGO_COLORS environment variable to
1719 specify the palette you want to use. For example, to specify the light
1720 palette under a Unix or OS/X BASH shell, you would run the following at
1721 a command prompt:
1722 export DJANGO_COLORS="light"
1724 You can also customize the colors that are used. Django specifies a
1726 number of roles in which color is used:
1727 · error - A major error.
1729 · notice - A minor error.
1731 · success - A success.
1733 · warning - A warning.
1735 · sql_field - The name of a model field in SQL.
1737 · sql_coltype - The type of a model field in SQL.
1739 · sql_keyword - An SQL keyword.
1741 · sql_table - The name of a model in SQL.
1743 · http_info - A 1XX HTTP Informational server response.
1745 · http_success - A 2XX HTTP Success server response.
1747 · http_not_modified - A 304 HTTP Not Modified server response.
1749 · http_redirect - A 3XX HTTP Redirect server response other than 304.
1751 · http_not_found - A 404 HTTP Not Found server response.
1753 · http_bad_request - A 4XX HTTP Bad Request server response other than
1755 404.
1756 · http_server_error - A 5XX HTTP Server Error response.
1758 · migrate_heading - A heading in a migrations management command.
1760 · migrate_label - A migration name.
1762 Each of these roles can be assigned a specific foreground and back‐
1764 ground color, from the following list:
1765 · black
1767 · red
1769 · green
1771 · yellow
1773 · blue
1775 · magenta
1777 · cyan
1779 · white
1781 Each of these colors can then be modified by using the following dis‐
1783 play options:
1784 · bold
1786 · underscore
1788 · blink
1790 · reverse
1792 · conceal
1794 A color specification follows one of the following patterns:
1796 · role=fg
1798 · role=fg/bg
1800 · role=fg,option,option
1802 · role=fg/bg,option,option
1804 where role is the name of a valid color role, fg is the foreground
1806 color, bg is the background color and each option is one of the color
1807 modifying options. Multiple color specifications are then separated by
1808 a semicolon. For example:
1809 export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
1811 would specify that errors be displayed using blinking yellow on blue,
1813 and notices displayed using magenta. All other color roles would be
1814 left uncolored.
1815 Colors can also be specified by extending a base palette. If you put a
1817 palette name in a color specification, all the colors implied by that
1818 palette will be loaded. So:
1819 export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
1821 would specify the use of all the colors in the light color palette,
1823 except for the colors for errors and notices which would be overridden
1824 as specified.
1825 Bash completion
1827 If you use the Bash shell, consider installing the Django bash comple‐
1828 tion script, which lives in extras/django_bash_completion in the Django
1829 source distribution. It enables tab-completion of django-admin and man‐
1830 age.py commands, so you can, for instance...
1831 · Type django-admin.
1833 · Press [TAB] to see all available options.
1835 · Type sql, then [TAB], to see all available options whose names start
1837 with sql.
1838 See /howto/custom-management-commands for how to add customized
1840 actions.
1841 django.core.management.call_command(name, *args, **options)
1843 To call a management command from code use call_command.
1845 name the name of the command to call or a command object. Passing the
1847 name is preferred unless the object is required for testing.
1848 *args a list of arguments accepted by the command. Arguments are
1850 passed to the argument parser, so you can use the same style as
1851 you would on the command line. For example, call_com‐
1852 mand('flush', '--verbosity=0').
1853 **options
1855 named options accepted on the command-line. Options are passed
1856 to the command without triggering the argument parser, which
1857 means you'll need to pass the correct type. For example,
1858 call_command('flush', verbosity=0) (zero must be an integer
1859 rather than a string).
1860 Examples:
1862 from django.core import management
1864 from django.core.management.commands import loaddata
1865 management.call_command('flush', verbosity=0, interactive=False)
1867 management.call_command('loaddata', 'test_data', verbosity=0)
1868 management.call_command(loaddata.Command(), 'test_data', verbosity=0)
1869 Note that command options that take no arguments are passed as keywords
1871 with True or False, as you can see with the interactive option above.
1872 Named arguments can be passed by using either one of the following syn‐
1874 taxes:
1875 # Similar to the command line
1877 management.call_command('dumpdata', '--natural-foreign')
1878 # Named argument similar to the command line minus the initial dashes and
1880 # with internal dashes replaced by underscores
1881 management.call_command('dumpdata', natural_foreign=True)
1882 # `use_natural_foreign_keys` is the option destination variable
1884 management.call_command('dumpdata', use_natural_foreign_keys=True)
1885 Some command options have different names when using call_command()
1887 instead of django-admin or manage.py. For example, django-admin create‐
1888 superuser --no-input translates to call_command('createsuperuser',
1889 interactive=False). To find what keyword argument name to use for
1890 call_command(), check the command's source code for the dest argument
1891 passed to parser.add_argument().
1892 Command options which take multiple options are passed a list:
1894 management.call_command('dumpdata', exclude=['contenttypes', 'auth'])
1896 The return value of the call_command() function is the same as the
1898 return value of the handle() method of the command.
1899
1901 Note that you can redirect standard output and error streams as all
1902 commands support the stdout and stderr options. For example, you could
1903 write:
1904 with open('/path/to/command_output', 'w') as f:
1906 management.call_command('dumpdata', stdout=f)
1907
1909 Django Software Foundation
1910
1912 Django Software Foundation and contributors
19133.0 November 18, 2019 DJANGO-ADMIN(1)