1DJANGO-ADMIN(1)                     Django                     DJANGO-ADMIN(1)
2
3
4

NAME

6       django-admin - Utility script for the Django web framework
7
8       django-admin is Django's command-line utility for administrative tasks.
9       This document outlines all it can do.
10
11       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
16       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
20       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
25       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

USAGE

30          $ django-admin <command> [options]
31          $ manage.py <command> [options]
32          $ python -m django <command> [options]
33
34       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
38   Getting runtime help
39       django-admin help
40
41       Run django-admin help to display usage information and a  list  of  the
42       commands provided by each application.
43
44       Run  django-admin  help  --commands  to display a list of all available
45       commands.
46
47       Run django-admin help <command> to display a description of  the  given
48       command and a list of its available options.
49
50   App names
51       Many commands take a list of "app names." An "app name" is the basename
52       of the package  containing  your  models.  For  example,  if  your  IN‐
53       STALLED_APPS contains the string 'mysite.blog', the app name is blog.
54
55   Determining the version
56       django-admin version
57
58       Run django-admin version to display the current Django version.
59
60       The output follows the schema described in PEP 440:
61
62          1.4.dev17026
63          1.4a1
64          1.4
65
66   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

AVAILABLE COMMANDS

71   check
72       django-admin check [app_label [app_label ...]]
73
74       Uses the system check framework to inspect the  entire  Django  project
75       for common problems.
76
77       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
80          django-admin check auth admin myapp
81
82       --tag TAGS, -t TAGS
83
84       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
89          django-admin check --tag models --tag compatibility
90
91       --database DATABASE
92
93       Specifies the database to run checks requiring database access:
94
95          django-admin check --database default --database other
96
97       By default, these checks will not be run.
98
99       --list-tags
100
101       Lists all available tags.
102
103       --deploy
104
105       Activates some additional checks that are only relevant in a deployment
106       setting.
107
108       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
114          django-admin check --deploy --settings=production_settings
115
116       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
120       --fail-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}
121
122       Specifies the message level that will cause the command to exit with  a
123       non-zero status. Default is ERROR.
124
125   compilemessages
126       django-admin compilemessages
127
128       Compiles  .po  files  created by makemessages to .mo files for use with
129       the built-in gettext support. See /topics/i18n/index.
130
131       --locale LOCALE, -l LOCALE
132
133       Specifies the locale(s) to process. If not provided,  all  locales  are
134       processed.
135
136       --exclude EXCLUDE, -x EXCLUDE
137
138       Specifies the locale(s) to exclude from processing. If not provided, no
139       locales are excluded.
140
141       --use-fuzzy, -f
142
143       Includes fuzzy translations into compiled files.
144
145       Example usage:
146
147          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
156       --ignore PATTERN, -i PATTERN
157
158       Ignores directories matching the given glob-style pattern. Use multiple
159       times to ignore more.
160
161       Example usage:
162
163          django-admin compilemessages --ignore=cache --ignore=outdated/*/locale
164
165   createcachetable
166       django-admin createcachetable
167
168       Creates  the cache tables for use with the database cache backend using
169       the information from your settings file. See /topics/cache for more in‐
170       formation.
171
172       --database DATABASE
173
174       Specifies the database in which the cache table(s) will be created. De‐
175       faults to default.
176
177       --dry-run
178
179       Prints the SQL that would be run without actually running  it,  so  you
180       can customize it or use the migrations framework.
181
182   dbshell
183       django-admin dbshell
184
185       Runs  the command-line client for the database engine specified in your
186       ENGINE setting, with the connection parameters specified in your  USER,
187       PASSWORD, etc., settings.
188
189       • For PostgreSQL, this runs the psql command-line client.
190
191       • For MySQL, this runs the mysql command-line client.
192
193       • For SQLite, this runs the sqlite3 command-line client.
194
195       • For Oracle, this runs the sqlplus command-line client.
196
197       This  command  assumes  the programs are on your PATH so that a call to
198       the program name (psql, mysql, sqlite3, sqlplus) will find the  program
199       in  the right place. There's no way to specify the location of the pro‐
200       gram manually.
201
202       --database DATABASE
203
204       Specifies the database onto which to open a shell. Defaults to default.
205
206       -- ARGUMENTS
207
208       Any arguments following a -- divider will be passed on to the  underly‐
209       ing  command-line  client. For example, with PostgreSQL you can use the
210       psql command's -c flag to execute a raw SQL query directly:
211
212          $ django-admin dbshell -- -c 'select current_user'
213           current_user
214          --------------
215           postgres
216          (1 row)
217
218       On MySQL/MariaDB, you can do this with the mysql command's -e flag:
219
220          $ django-admin dbshell -- -e "select user()"
221          +----------------------+
222          | user()               |
223          +----------------------+
224          | djangonaut@localhost |
225          +----------------------+
226
227       NOTE:
228          Be aware that not all options set in the OPTIONS part of your  data‐
229          base  configuration  in  DATABASES  are  passed  to the command-line
230          client, e.g. 'isolation_level'.
231
232   diffsettings
233       django-admin diffsettings
234
235       Displays differences between the current settings file and Django's de‐
236       fault settings (or another settings file specified by --default).
237
238       Settings  that  don't appear in the defaults are followed by "###". For
239       example, the default settings don't define ROOT_URLCONF,  so  ROOT_URL‐
240       CONF is followed by "###" in the output of diffsettings.
241
242       --all
243
244       Displays  all  settings, even if they have Django's default value. Such
245       settings are prefixed by "###".
246
247       --default MODULE
248
249       The settings module to compare  the  current  settings  against.  Leave
250       empty to compare against Django's default settings.
251
252       --output {hash,unified}
253
254       Specifies  the  output  format.  Available values are hash and unified.
255       hash is the default mode that  displays  the  output  that's  described
256       above.   unified  displays  the output similar to diff -u. Default set‐
257       tings are prefixed with a minus sign, followed by the  changed  setting
258       prefixed with a plus sign.
259
260   dumpdata
261       django-admin   dumpdata  [app_label[.ModelName]  [app_label[.ModelName]
262       ...]]
263
264       Outputs to standard output all data in the database associated with the
265       named application(s).
266
267       If  no application name is provided, all installed applications will be
268       dumped.
269
270       The output of dumpdata can be used as input for loaddata.
271
272       Note that dumpdata uses the default manager on the model for  selecting
273       the  records  to  dump. If you're using a custom manager as the default
274       manager and it filters some of the available records, not  all  of  the
275       objects will be dumped.
276
277       --all, -a
278
279       Uses  Django's  base  manager, dumping records which might otherwise be
280       filtered or modified by a custom manager.
281
282       --format FORMAT
283
284       Specifies the serialization format of the  output.  Defaults  to  JSON.
285       Supported formats are listed in serialization-formats.
286
287       --indent INDENT
288
289       Specifies  the  number  of indentation spaces to use in the output. De‐
290       faults to None which displays all data on single line.
291
292       --exclude EXCLUDE, -e EXCLUDE
293
294       Prevents specific applications or models  (specified  in  the  form  of
295       app_label.ModelName)  from  being  dumped. If you specify a model name,
296       then only that model will be excluded, rather than the entire  applica‐
297       tion. You can also mix application names and model names.
298
299       If  you want to exclude multiple applications, pass --exclude more than
300       once:
301
302          django-admin dumpdata --exclude=auth --exclude=contenttypes
303
304       --database DATABASE
305
306       Specifies the database from which data will be dumped. Defaults to  de‐
307       fault.
308
309       --natural-foreign
310
311       Uses  the  natural_key()  model method to serialize any foreign key and
312       many-to-many relationship to objects  of  the  type  that  defines  the
313       method.  If  you're  dumping  contrib.auth  Permission  objects or con‐
314       trib.contenttypes ContentType objects, you  should  probably  use  this
315       flag.  See  the natural keys documentation for more details on this and
316       the next option.
317
318       --natural-primary
319
320       Omits the primary key in the serialized data of this  object  since  it
321       can be calculated during deserialization.
322
323       --pks PRIMARY_KEYS
324
325       Outputs only the objects specified by a comma separated list of primary
326       keys.  This is only available when dumping one model. By  default,  all
327       the records of the model are output.
328
329       --output OUTPUT, -o OUTPUT
330
331       Specifies  a file to write the serialized data to. By default, the data
332       goes to standard output.
333
334       When this option is set and --verbosity is  greater  than  0  (the  de‐
335       fault), a progress bar is shown in the terminal.
336
337   Fixtures compression
338       The  output file can be compressed with one of the bz2, gz, lzma, or xz
339       formats by ending the filename with the corresponding  extension.   For
340       example, to output the data as a compressed JSON file:
341
342          django-admin dumpdata -o mydata.json.gz
343
344   flush
345       django-admin flush
346
347       Removes  all  data  from the database and re-executes any post-synchro‐
348       nization handlers. The table of which migrations have been  applied  is
349       not cleared.
350
351       If  you would rather start from an empty database and re-run all migra‐
352       tions, you should drop and recreate the database and then  run  migrate
353       instead.
354
355       --noinput, --no-input
356
357       Suppresses all user prompts.
358
359       --database DATABASE
360
361       Specifies the database to flush. Defaults to default.
362
363   inspectdb
364       django-admin inspectdb [table [table ...]]
365
366       Introspects  the database tables in the database pointed-to by the NAME
367       setting and outputs a Django model module (a models.py file)  to  stan‐
368       dard output.
369
370       You  may  choose what tables or views to inspect by passing their names
371       as arguments. If no arguments are  provided,  models  are  created  for
372       views  only if the --include-views option is used. Models for partition
373       tables are created on PostgreSQL if the --include-partitions option  is
374       used.
375
376       Use  this  if  you  have a legacy database with which you'd like to use
377       Django.  The script will inspect the database and create  a  model  for
378       each table within it.
379
380       As  you might expect, the created models will have an attribute for ev‐
381       ery field in the table. Note that inspectdb has a few special cases  in
382       its field-name output:
383
384       • If  inspectdb cannot map a column's type to a model field type, it'll
385         use TextField and will insert the Python comment 'This field type  is
386         a  guess.'  next  to the field in the generated model. The recognized
387         fields may depend on apps  listed  in  INSTALLED_APPS.  For  example,
388         django.contrib.postgres  adds recognition for several PostgreSQL-spe‐
389         cific field types.
390
391       • If the database column name  is  a  Python  reserved  word  (such  as
392         'pass',  'class' or 'for'), inspectdb will append '_field' to the at‐
393         tribute name. For example, if a table has a column 'for', the  gener‐
394         ated  model  will have a field 'for_field', with the db_column attri‐
395         bute set to 'for'. inspectdb will insert the  Python  comment  'Field
396         renamed because it was a Python reserved word.' next to the field.
397
398       This  feature  is  meant as a shortcut, not as definitive model genera‐
399       tion. After you run it, you'll want to look over the  generated  models
400       yourself  to  make  customizations.  In  particular, you'll need to re‐
401       arrange models' order, so that models that refer to  other  models  are
402       ordered properly.
403
404       Django  doesn't create database defaults when a default is specified on
405       a model field.  Similarly, database defaults aren't translated to model
406       field defaults or detected in any fashion by inspectdb.
407
408       By  default,  inspectdb  creates  unmanaged  models. That is, managed =
409       False in the model's Meta class tells Django not to manage each table's
410       creation, modification, and deletion. If you do want to allow Django to
411       manage the table's lifecycle, you'll need to change the managed  option
412       to True (or remove it because True is its default value).
413
414   Database-specific notes
415   Oracle
416       • Models are created for materialized views if --include-views is used.
417
418   PostgreSQL
419       • Models are created for foreign tables.
420
421       • Models are created for materialized views if --include-views is used.
422
423       • Models  are  created  for partition tables if --include-partitions is
424         used.
425
426       --database DATABASE
427
428       Specifies the database to introspect. Defaults to default.
429
430       --include-partitions
431
432       If this option is provided, models are also created for partitions.
433
434       Only support for PostgreSQL is implemented.
435
436       --include-views
437
438       If this option is provided, models are also created for database views.
439
440   loaddata
441       django-admin loaddata fixture [fixture ...]
442
443       Searches for and loads the contents of the named fixture into the data‐
444       base.
445
446       --database DATABASE
447
448       Specifies  the database into which the data will be loaded. Defaults to
449       default.
450
451       --ignorenonexistent, -i
452
453       Ignores fields and models that may have been removed since the  fixture
454       was originally generated.
455
456       --app APP_LABEL
457
458       Specifies  a  single app to look for fixtures in rather than looking in
459       all apps.
460
461       --format FORMAT
462
463       Specifies the serialization format (e.g., json  or  xml)  for  fixtures
464       read from stdin.
465
466       --exclude EXCLUDE, -e EXCLUDE
467
468       Excludes loading the fixtures from the given applications and/or models
469       (in the form of app_label or app_label.ModelName). Use the option  mul‐
470       tiple times to exclude more than one app or model.
471
472   What's a fixture ?
473       A fixture is a collection of files that contain the serialized contents
474       of the database. Each fixture has a unique name,  and  the  files  that
475       comprise  the  fixture can be distributed over multiple directories, in
476       multiple applications.
477
478       Django will search in three locations for fixtures:
479
480       1. In the fixtures directory of every installed application
481
482       2. In any directory named in the FIXTURE_DIRS setting
483
484       3. In the literal path named by the fixture
485
486       Django will load any and all fixtures it finds in these locations  that
487       match the provided fixture names.
488
489       If  the  named fixture has a file extension, only fixtures of that type
490       will be loaded. For example:
491
492          django-admin loaddata mydata.json
493
494       would only load JSON fixtures called mydata. The fixture extension must
495       correspond to the registered name of a serializer (e.g., json or xml).
496
497       If  you  omit  the extensions, Django will search all available fixture
498       types for a matching fixture. For example:
499
500          django-admin loaddata mydata
501
502       would look for any fixture of any fixture type called mydata. If a fix‐
503       ture directory contained mydata.json, that fixture would be loaded as a
504       JSON fixture.
505
506       The fixtures that are named can include directory components. These di‐
507       rectories will be included in the search path. For example:
508
509          django-admin loaddata foo/bar/mydata.json
510
511       would  search  <app_label>/fixtures/foo/bar/mydata.json  for  each  in‐
512       stalled application,  <dirname>/foo/bar/mydata.json for each  directory
513       in FIXTURE_DIRS, and the literal path foo/bar/mydata.json.
514
515       When  fixture files are processed, the data is saved to the database as
516       is.  Model defined save() methods are not called, and any  pre_save  or
517       post_save  signals will be called with raw=True since the instance only
518       contains attributes that are local to the model. You may, for  example,
519       want to disable handlers that access related fields that aren't present
520       during fixture loading and would otherwise raise an exception:
521
522          from django.db.models.signals import post_save
523          from .models import MyModel
524
525          def my_handler(**kwargs):
526              # disable the handler during fixture loading
527              if kwargs['raw']:
528                  return
529              ...
530
531          post_save.connect(my_handler, sender=MyModel)
532
533       You could also write a decorator to encapsulate this logic:
534
535          from functools import wraps
536
537          def disable_for_loaddata(signal_handler):
538              """
539              Decorator that turns off signal handlers when loading fixture data.
540              """
541              @wraps(signal_handler)
542              def wrapper(*args, **kwargs):
543                  if kwargs['raw']:
544                      return
545                  signal_handler(*args, **kwargs)
546              return wrapper
547
548          @disable_for_loaddata
549          def my_handler(**kwargs):
550              ...
551
552       Just be aware that this logic will disable the  signals  whenever  fix‐
553       tures are deserialized, not just during loaddata.
554
555       Note  that the order in which fixture files are processed is undefined.
556       However, all fixture data is installed as a single transaction, so data
557       in  one  fixture can reference data in another fixture. If the database
558       backend supports  row-level  constraints,  these  constraints  will  be
559       checked at the end of the transaction.
560
561       The dumpdata command can be used to generate input for loaddata.
562
563   Compressed fixtures
564       Fixtures may be compressed in zip, gz, bz2, lzma, or xz format. For ex‐
565       ample:
566
567          django-admin loaddata mydata.json
568
569       would look for any of mydata.json, mydata.json.zip, mydata.json.gz, my‐
570       data.json.bz2, mydata.json.lzma, or mydata.json.xz. The first file con‐
571       tained within a compressed archive is used.
572
573       Note that if two fixtures with the same name but different fixture type
574       are  discovered  (for  example,  if  mydata.json and mydata.xml.gz were
575       found in the same fixture  directory),  fixture  installation  will  be
576       aborted, and any data installed in the call to loaddata will be removed
577       from the database.
578
579          MySQL with MyISAM and fixtures
580
581                 The MyISAM storage engine of MySQL doesn't  support  transac‐
582                 tions  or  constraints,  so  if you use MyISAM, you won't get
583                 validation of fixture data, or a rollback if multiple  trans‐
584                 action files are found.
585
586       Support for XZ archives (.xz) and LZMA archives (.lzma) was added.
587
588
589   Database-specific fixtures
590       If  you're  in a multi-database setup, you might have fixture data that
591       you want to load onto one database, but not onto another. In this situ‐
592       ation,  you  can  add a database identifier into the names of your fix‐
593       tures.
594
595       For example, if your DATABASES setting has a 'master' database defined,
596       name  the  fixture  mydata.master.json or mydata.master.json.gz and the
597       fixture will only be loaded when you specify you want to load data into
598       the master database.
599
600   Loading fixtures from stdin
601       You  can  use  a dash as the fixture name to load input from sys.stdin.
602       For example:
603
604          django-admin loaddata --format=json -
605
606       When reading from stdin, the --format option is required to specify the
607       serialization format of the input (e.g., json or xml).
608
609       Loading  from  stdin  is useful with standard input and output redirec‐
610       tions.  For example:
611
612          django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -
613
614   makemessages
615       django-admin makemessages
616
617       Runs over the entire source tree of the current directory and pulls out
618       all  strings  marked for translation. It creates (or updates) a message
619       file in the conf/locale (in the Django tree) or locale (for project and
620       application)  directory. After making changes to the messages files you
621       need to compile them with compilemessages for use with the builtin get‐
622       text support. See the i18n documentation for details.
623
624       This  command  doesn't  require configured settings. However, when set‐
625       tings aren't configured, the command can't ignore  the  MEDIA_ROOT  and
626       STATIC_ROOT directories or include LOCALE_PATHS.
627
628       --all, -a
629
630       Updates the message files for all available languages.
631
632       --extension EXTENSIONS, -e EXTENSIONS
633
634       Specifies  a list of file extensions to examine (default: html, txt, py
635       or js if --domain is js).
636
637       Example usage:
638
639          django-admin makemessages --locale=de --extension xhtml
640
641       Separate multiple extensions with commas or use -e or --extension  mul‐
642       tiple times:
643
644          django-admin makemessages --locale=de --extension=html,txt --extension xml
645
646       --locale LOCALE, -l LOCALE
647
648       Specifies the locale(s) to process.
649
650       --exclude EXCLUDE, -x EXCLUDE
651
652       Specifies the locale(s) to exclude from processing. If not provided, no
653       locales are excluded.
654
655       Example usage:
656
657          django-admin makemessages --locale=pt_BR
658          django-admin makemessages --locale=pt_BR --locale=fr
659          django-admin makemessages -l pt_BR
660          django-admin makemessages -l pt_BR -l fr
661          django-admin makemessages --exclude=pt_BR
662          django-admin makemessages --exclude=pt_BR --exclude=fr
663          django-admin makemessages -x pt_BR
664          django-admin makemessages -x pt_BR -x fr
665
666       --domain DOMAIN, -d DOMAIN
667
668       Specifies the domain of the messages files. Supported options are:
669
670django for all *.py, *.html and *.txt files (default)
671
672djangojs for *.js files
673
674       --symlinks, -s
675
676       Follows symlinks  to  directories  when  looking  for  new  translation
677       strings.
678
679       Example usage:
680
681          django-admin makemessages --locale=de --symlinks
682
683       --ignore PATTERN, -i PATTERN
684
685       Ignores files or directories matching the given glob-style pattern. Use
686       multiple times to ignore more.
687
688       These patterns are used by default: 'CVS', '.*', '*~', '*.pyc'.
689
690       Example usage:
691
692          django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html
693
694       --no-default-ignore
695
696       Disables the default values of --ignore.
697
698       --no-wrap
699
700       Disables breaking long message lines into  several  lines  in  language
701       files.
702
703       --no-location
704
705       Suppresses  writing '#: filename:line’ comment lines in language files.
706       Using this option makes it harder for technically  skilled  translators
707       to understand each message's context.
708
709       --add-location [{full,file,never}]
710
711       Controls  #:  filename:line comment lines in language files. If the op‐
712       tion is:
713
714full (the default if not given): the lines include both file name and
715         line number.
716
717file: the line number is omitted.
718
719never: the lines are suppressed (same as --no-location).
720
721       Requires gettext 0.19 or newer.
722
723       --keep-pot
724
725       Prevents  deleting  the  temporary .pot files generated before creating
726       the .po file. This is useful for debugging errors which may prevent the
727       final language files from being created.
728
729       SEE ALSO:
730          See  customizing-makemessages  for  instructions on how to customize
731          the keywords that makemessages passes to xgettext.
732
733   makemigrations
734       django-admin makemigrations [app_label [app_label ...]]
735
736       Creates new migrations based on the changes detected  to  your  models.
737       Migrations,  their relationship with apps and more are covered in depth
738       in the migrations documentation.
739
740       Providing one or more app names as arguments will limit the  migrations
741       created  to the app(s) specified and any dependencies needed (the table
742       at the other end of a ForeignKey, for example).
743
744       To add migrations to an app that doesn't have a  migrations  directory,
745       run makemigrations with the app's app_label.
746
747       --noinput, --no-input
748
749       Suppresses  all user prompts. If a suppressed prompt cannot be resolved
750       automatically, the command will exit with error code 3.
751
752       --empty
753
754       Outputs an empty migration for the specified apps, for manual  editing.
755       This is for advanced users and should not be used unless you are famil‐
756       iar with the migration format, migration operations, and the  dependen‐
757       cies between your migrations.
758
759       --dry-run
760
761       Shows what migrations would be made without actually writing any migra‐
762       tions files to disk. Using this option along with  --verbosity  3  will
763       also show the complete migrations files that would be written.
764
765       --merge
766
767       Enables fixing of migration conflicts.
768
769       --name NAME, -n NAME
770
771       Allows  naming  the generated migration(s) instead of using a generated
772       name. The name must be a valid Python identifier.
773
774       --no-header
775
776       Generate migration files without Django version and timestamp header.
777
778       --check
779
780       Makes makemigrations exit with a non-zero  status  when  model  changes
781       without migrations are detected.
782
783       Support  for  calling makemigrations without an active database connec‐
784       tion was added. In that case, check for a consistent migration  history
785       is skipped.
786
787
788   migrate
789       django-admin migrate [app_label] [migration_name]
790
791       Synchronizes  the database state with the current set of models and mi‐
792       grations.  Migrations, their relationship with apps and more  are  cov‐
793       ered in depth in the migrations documentation.
794
795       The  behavior  of  this command changes depending on the arguments pro‐
796       vided:
797
798       • No arguments: All apps have all of their migrations run.
799
800<app_label>: The specified app has its migrations run, up to the most
801         recent  migration.  This  may  involve running other apps' migrations
802         too, due to dependencies.
803
804<app_label> <migrationname>: Brings the database schema  to  a  state
805         where  the named migration is applied, but no later migrations in the
806         same app are applied. This may involve unapplying migrations  if  you
807         have previously migrated past the named migration. You can use a pre‐
808         fix of the migration name, e.g. 0001, as long as it's unique for  the
809         given app name. Use the name zero to migrate all the way back i.e. to
810         revert all applied migrations for an app.
811
812       WARNING:
813          When unapplying migrations, all dependent migrations  will  also  be
814          unapplied,  regardless  of  <app_label>. You can use --plan to check
815          which migrations will be unapplied.
816
817       --database DATABASE
818
819       Specifies the database to migrate. Defaults to default.
820
821       --fake
822
823       Marks the migrations up to the target one (following the  rules  above)
824       as  applied,  but without actually running the SQL to change your data‐
825       base schema.
826
827       This is intended for advanced users to manipulate the current migration
828       state directly if they're manually applying changes; be warned that us‐
829       ing --fake runs the risk of putting the migration state  table  into  a
830       state  where manual recovery will be needed to make migrations run cor‐
831       rectly.
832
833       --fake-initial
834
835       Allows Django to skip an app's initial migration if all database tables
836       with  the  names of all models created by all CreateModel operations in
837       that migration already exist. This option  is  intended  for  use  when
838       first  running migrations against a database that preexisted the use of
839       migrations. This option does not, however, check for matching  database
840       schema  beyond  matching  table names and so is only safe to use if you
841       are confident that your existing schema matches  what  is  recorded  in
842       your initial migration.
843
844       --plan
845
846       Shows the migration operations that will be performed for the given mi‐
847       grate command.
848
849       --run-syncdb
850
851       Allows creating tables for apps without migrations.  While  this  isn't
852       recommended,  the  migrations  framework is sometimes too slow on large
853       projects with hundreds of models.
854
855       --noinput, --no-input
856
857       Suppresses all user prompts. An example prompt is asking about removing
858       stale content types.
859
860       --check
861
862       Makes migrate exit with a non-zero status when unapplied migrations are
863       detected.
864
865   runserver
866       django-admin runserver [addrport]
867
868       Starts a lightweight development web server on the  local  machine.  By
869       default,  the server runs on port 8000 on the IP address 127.0.0.1. You
870       can pass in an IP address and port number explicitly.
871
872       If you run this script as a user with normal privileges  (recommended),
873       you  might  not  have  access to start a port on a low port number. Low
874       port numbers are reserved for the superuser (root).
875
876       This server uses the WSGI application object specified by the  WSGI_AP‐
877       PLICATION setting.
878
879       DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through
880       security audits or performance tests. (And that's how it's gonna  stay.
881       We're in the business of making web frameworks, not web servers, so im‐
882       proving this server to be able to handle a  production  environment  is
883       outside the scope of Django.)
884
885       The  development  server automatically reloads Python code for each re‐
886       quest, as needed. You don't need to restart the server for code changes
887       to  take effect.  However, some actions like adding files don't trigger
888       a restart, so you'll have to restart the server in these cases.
889
890       If you're using Linux or MacOS and  install  both  pywatchman  and  the
891       Watchman  service, kernel signals will be used to autoreload the server
892       (rather than polling file modification timestamps  each  second).  This
893       offers  better performance on large projects, reduced response time af‐
894       ter code changes, more robust change  detection,  and  a  reduction  in
895       power usage. Django supports pywatchman 1.2.0 and higher.
896
897          Large directories with many files may cause performance issues
898
899                 When  using  Watchman  with  a  project  that  includes large
900                 non-Python directories like node_modules, it's  advisable  to
901                 ignore  this  directory  for  optimal  performance.  See  the
902                 watchman documentation for information on how to do this.
903
904          Watchman timeout
905
906          DJANGO_WATCHMAN_TIMEOUT
907
908          The default timeout of Watchman client is 5 seconds. You can  change
909          it by setting the DJANGO_WATCHMAN_TIMEOUT environment variable.
910
911       When  you  start the server, and each time you change Python code while
912       the server is running, the system check framework will check  your  en‐
913       tire  Django project for some common errors (see the check command). If
914       any errors are found, they will be printed to standard output. You  can
915       use the --skip-checks option to skip running system checks.
916
917       You  can run as many concurrent servers as you want, as long as they're
918       on separate ports by executing django-admin runserver more than once.
919
920       Note that the default IP address, 127.0.0.1,  is  not  accessible  from
921       other  machines  on your network. To make your development server view‐
922       able to other machines on the network, use its  own  IP  address  (e.g.
923       192.168.2.1) or 0.0.0.0 or :: (with IPv6 enabled).
924
925       You   can   provide  an  IPv6  address  surrounded  by  brackets  (e.g.
926       [200a::1]:8000). This will automatically enable IPv6 support.
927
928       A hostname containing ASCII-only characters can also be used.
929
930       If the staticfiles contrib app is enabled (default in new projects) the
931       runserver command will be overridden with its own runserver command.
932
933       Logging  of  each  request  and  response  of the server is sent to the
934       django-server-logger logger.
935
936       --noreload
937
938       Disables the auto-reloader. This means any Python code changes you make
939       while  the  server  is  running  will not take effect if the particular
940       Python modules have already been loaded into memory.
941
942       --nothreading
943
944       Disables use of threading in the development server. The server is mul‐
945       tithreaded by default.
946
947       --ipv6, -6
948
949       Uses  IPv6  for the development server. This changes the default IP ad‐
950       dress from 127.0.0.1 to ::1.
951
952       Support for the --skip-checks option was added.
953
954
955   Examples of using different ports and addresses
956       Port 8000 on IP address 127.0.0.1:
957
958          django-admin runserver
959
960       Port 8000 on IP address 1.2.3.4:
961
962          django-admin runserver 1.2.3.4:8000
963
964       Port 7000 on IP address 127.0.0.1:
965
966          django-admin runserver 7000
967
968       Port 7000 on IP address 1.2.3.4:
969
970          django-admin runserver 1.2.3.4:7000
971
972       Port 8000 on IPv6 address ::1:
973
974          django-admin runserver -6
975
976       Port 7000 on IPv6 address ::1:
977
978          django-admin runserver -6 7000
979
980       Port 7000 on IPv6 address 2001:0db8:1234:5678::9:
981
982          django-admin runserver [2001:0db8:1234:5678::9]:7000
983
984       Port 8000 on IPv4 address of host localhost:
985
986          django-admin runserver localhost:8000
987
988       Port 8000 on IPv6 address of host localhost:
989
990          django-admin runserver -6 localhost:8000
991
992   Serving static files with the development server
993       By default, the development server doesn't serve any static  files  for
994       your  site  (such  as  CSS files, images, things under MEDIA_URL and so
995       forth). If you want to configure Django to  serve  static  media,  read
996       /howto/static-files/index.
997
998   sendtestemail
999       django-admin sendtestemail [email [email ...]]
1000
1001       Sends a test email (to confirm email sending through Django is working)
1002       to the recipient(s) specified. For example:
1003
1004          django-admin sendtestemail foo@example.com bar@example.com
1005
1006       There are a couple of options, and you may use any combination of  them
1007       together:
1008
1009       --managers
1010
1011       Mails the email addresses specified in MANAGERS using mail_managers().
1012
1013       --admins
1014
1015       Mails the email addresses specified in ADMINS using mail_admins().
1016
1017   shell
1018       django-admin shell
1019
1020       Starts the Python interactive interpreter.
1021
1022       --interface {ipython,bpython,python}, -i {ipython,bpython,python}
1023
1024       Specifies  the  shell  to  use.  By default, Django will use IPython or
1025       bpython if either is installed. If both are  installed,  specify  which
1026       one you want like so:
1027
1028       IPython:
1029
1030          django-admin shell -i ipython
1031
1032       bpython:
1033
1034          django-admin shell -i bpython
1035
1036       If  you  have  a  "rich"  shell  installed but want to force use of the
1037       "plain" Python interpreter, use python as the interface name, like so:
1038
1039          django-admin shell -i python
1040
1041       --nostartup
1042
1043       Disables reading the startup script for the "plain" Python interpreter.
1044       By  default,  the  script  pointed  to by the PYTHONSTARTUP environment
1045       variable or the ~/.pythonrc.py script is read.
1046
1047       --command COMMAND, -c COMMAND
1048
1049       Lets you pass a command as a string to execute it as Django, like so:
1050
1051          django-admin shell --command="import django; print(django.__version__)"
1052
1053       You can also pass code in on standard input to execute it. For example:
1054
1055          $ django-admin shell <<EOF
1056          > import django
1057          > print(django.__version__)
1058          > EOF
1059
1060       On Windows,  the  REPL  is  output  due  to  implementation  limits  of
1061       select.select() on that platform.
1062
1063   showmigrations
1064       django-admin showmigrations [app_label [app_label ...]]
1065
1066       Shows  all migrations in a project. You can choose from one of two for‐
1067       mats:
1068
1069       --list, -l
1070
1071       Lists all of the apps Django knows about, the migrations available  for
1072       each  app,  and  whether or not each migration is applied (marked by an
1073       [X] next to the migration name). For a --verbosity of 2 and above,  the
1074       applied datetimes are also shown.
1075
1076       Apps  without  migrations  are  also  listed,  but have (no migrations)
1077       printed under them.
1078
1079       This is the default output format.
1080
1081       --plan, -p
1082
1083       Shows the migration plan Django will follow to apply  migrations.  Like
1084       --list, applied migrations are marked by an [X]. For a --verbosity of 2
1085       and above, all dependencies of a migration will also be shown.
1086
1087       app_labels arguments limit the output, however,  dependencies  of  pro‐
1088       vided apps may also be included.
1089
1090       --database DATABASE
1091
1092       Specifies the database to examine. Defaults to default.
1093
1094   sqlflush
1095       django-admin sqlflush
1096
1097       Prints the SQL statements that would be executed for the flush command.
1098
1099       --database DATABASE
1100
1101       Specifies the database for which to print the SQL. Defaults to default.
1102
1103   sqlmigrate
1104       django-admin sqlmigrate app_label migration_name
1105
1106       Prints  the  SQL for the named migration. This requires an active data‐
1107       base connection, which it will use to resolve  constraint  names;  this
1108       means you must generate the SQL against a copy of the database you wish
1109       to later apply it on.
1110
1111       Note that sqlmigrate doesn't colorize its output.
1112
1113       --backwards
1114
1115       Generates the SQL for unapplying the migration.  By  default,  the  SQL
1116       created is for running the migration in the forwards direction.
1117
1118       --database DATABASE
1119
1120       Specifies  the  database for which to generate the SQL. Defaults to de‐
1121       fault.
1122
1123   sqlsequencereset
1124       django-admin sqlsequencereset app_label [app_label ...]
1125
1126       Prints the SQL statements for resetting sequences  for  the  given  app
1127       name(s).
1128
1129       Sequences  are  indexes used by some database engines to track the next
1130       available number for automatically incremented fields.
1131
1132       Use this command to generate SQL which will fix cases where a  sequence
1133       is out of sync with its automatically incremented field data.
1134
1135       --database DATABASE
1136
1137       Specifies the database for which to print the SQL. Defaults to default.
1138
1139   squashmigrations
1140       django-admin  squashmigrations  app_label [start_migration_name] migra‐
1141       tion_name
1142
1143       Squashes the migrations  for  app_label  up  to  and  including  migra‐
1144       tion_name  down  into  fewer  migrations,  if  possible.  The resulting
1145       squashed migrations can live alongside the unsquashed ones safely.  For
1146       more information, please read migration-squashing.
1147
1148       When start_migration_name is given, Django will only include migrations
1149       starting from and including this migration. This helps to mitigate  the
1150       squashing   limitation  of  RunPython  and  django.db.migrations.opera‐
1151       tions.RunSQL migration operations.
1152
1153       --no-optimize
1154
1155       Disables the optimizer when generating a  squashed  migration.  By  de‐
1156       fault, Django will try to optimize the operations in your migrations to
1157       reduce the size of the resulting file. Use this option if this  process
1158       is  failing or creating incorrect migrations, though please also file a
1159       Django bug report about the behavior, as optimization is  meant  to  be
1160       safe.
1161
1162       --noinput, --no-input
1163
1164       Suppresses all user prompts.
1165
1166       --squashed-name SQUASHED_NAME
1167
1168       Sets  the  name  of  the  squashed migration. When omitted, the name is
1169       based on the first and last migration, with _squashed_ in between.
1170
1171       --no-header
1172
1173       Generate squashed migration file without Django version  and  timestamp
1174       header.
1175
1176   startapp
1177       django-admin startapp name [directory]
1178
1179       Creates  a Django app directory structure for the given app name in the
1180       current directory or the given destination.
1181
1182       By default, the new directory contains a models.py file and  other  app
1183       template  files.  If only the app name is given, the app directory will
1184       be created in the current working directory.
1185
1186       If the optional destination is provided, Django will use that  existing
1187       directory rather than creating a new one. You can use '.' to denote the
1188       current working directory.
1189
1190       For example:
1191
1192          django-admin startapp myapp /Users/jezdez/Code/myapp
1193
1194       --template TEMPLATE
1195
1196       Provides the path to a directory with a custom app template file, or  a
1197       path  to  an  uncompressed  archive  (.tar)  or  a  compressed  archive
1198       (.tar.gz, .tar.bz2, .tar.xz, .tar.lzma, .tgz, .tbz2, .txz, .tlz,  .zip)
1199       containing the app template files.
1200
1201       For example, this would look for an app template in the given directory
1202       when creating the myapp app:
1203
1204          django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp
1205
1206       Django will also accept URLs (http, https, ftp) to compressed  archives
1207       with  the  app  template  files, downloading and extracting them on the
1208       fly.
1209
1210       For example, taking advantage of GitHub's feature to  expose  reposito‐
1211       ries as zip files, you can use a URL like:
1212
1213          django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip myapp
1214
1215       --extension EXTENSIONS, -e EXTENSIONS
1216
1217       Specifies  which file extensions in the app template should be rendered
1218       with the template engine. Defaults to py.
1219
1220       --name FILES, -n FILES
1221
1222       Specifies which files in the app template (in addition to those  match‐
1223       ing  --extension) should be rendered with the template engine. Defaults
1224       to an empty list.
1225
1226       --exclude DIRECTORIES, -x DIRECTORIES
1227
1228
1229
1230       Specifies which directories in the app template should be excluded,  in
1231       addition  to  .git and __pycache__. If this option is not provided, di‐
1232       rectories named __pycache__ or starting with . will be excluded.
1233
1234       The template context used for all matching files is:
1235
1236       • Any option passed to the startapp command (among the  command's  sup‐
1237         ported options)
1238
1239app_name -- the app name as passed to the command
1240
1241app_directory -- the full path of the newly created app
1242
1243camel_case_app_name -- the app name in camel case format
1244
1245docs_version -- the version of the documentation: 'dev' or '1.x'
1246
1247django_version -- the version of Django, e.g. '2.0.3'
1248
1249       WARNING:
1250          When  the  app  template files are rendered with the Django template
1251          engine (by default all *.py files), Django  will  also  replace  all
1252          stray  template  variables  contained.  For  example,  if one of the
1253          Python files contains a docstring explaining  a  particular  feature
1254          related to template rendering, it might result in an incorrect exam‐
1255          ple.
1256
1257          To work around this problem, you can use  the  templatetag  template
1258          tag to "escape" the various parts of the template syntax.
1259
1260          In addition, to allow Python template files that contain Django tem‐
1261          plate language syntax while also preventing packaging  systems  from
1262          trying  to  byte-compile  invalid  *.py files, template files ending
1263          with .py-tpl will be renamed to .py.
1264
1265   startproject
1266       django-admin startproject name [directory]
1267
1268       Creates a Django project directory structure for the given project name
1269       in the current directory or the given destination.
1270
1271       By  default, the new directory contains manage.py and a project package
1272       (containing a settings.py and other files).
1273
1274       If only the project name is  given,  both  the  project  directory  and
1275       project  package  will be named <projectname> and the project directory
1276       will be created in the current working directory.
1277
1278       If the optional destination is provided, Django will use that  existing
1279       directory  as  the  project  directory,  and  create  manage.py and the
1280       project package within it. Use '.' to denote the current working direc‐
1281       tory.
1282
1283       For example:
1284
1285          django-admin startproject myproject /Users/jezdez/Code/myproject_repo
1286
1287       --template TEMPLATE
1288
1289       Specifies  a directory, file path, or URL of a custom project template.
1290       See the startapp --template documentation for examples and usage.
1291
1292       --extension EXTENSIONS, -e EXTENSIONS
1293
1294       Specifies which file extensions in the project template should be  ren‐
1295       dered with the template engine. Defaults to py.
1296
1297       --name FILES, -n FILES
1298
1299       Specifies  which  files  in  the project template (in addition to those
1300       matching --extension) should be rendered with the template engine.  De‐
1301       faults to an empty list.
1302
1303       --exclude DIRECTORIES, -x DIRECTORIES
1304
1305
1306
1307       Specifies which directories in the project template should be excluded,
1308       in addition to .git and __pycache__. If this option  is  not  provided,
1309       directories named __pycache__ or starting with . will be excluded.
1310
1311       The template context used is:
1312
1313       • Any  option  passed  to the startproject command (among the command's
1314         supported options)
1315
1316project_name -- the project name as passed to the command
1317
1318project_directory -- the full path of the newly created project
1319
1320secret_key -- a random key for the SECRET_KEY setting
1321
1322docs_version -- the version of the documentation: 'dev' or '1.x'
1323
1324django_version -- the version of Django, e.g. '2.0.3'
1325
1326       Please also see the rendering warning as mentioned for startapp.
1327
1328   test
1329       django-admin test [test_label [test_label ...]]
1330
1331       Runs tests for all installed apps. See /topics/testing/index  for  more
1332       information.
1333
1334       --failfast
1335
1336       Stops  running  tests  and reports the failure immediately after a test
1337       fails.
1338
1339       --testrunner TESTRUNNER
1340
1341       Controls the test runner class that is  used  to  execute  tests.  This
1342       value overrides the value provided by the TEST_RUNNER setting.
1343
1344       --noinput, --no-input
1345
1346       Suppresses all user prompts. A typical prompt is a warning about delet‐
1347       ing an existing test database.
1348
1349   Test runner options
1350       The  test  command  receives  options  on  behalf  of   the   specified
1351       --testrunner. These are the options of the default test runner: Discov‐
1352       erRunner.
1353
1354       --keepdb
1355
1356       Preserves the test database between test runs. This has  the  advantage
1357       of  skipping  both the create and destroy actions which can greatly de‐
1358       crease the time to run tests, especially those in a large  test  suite.
1359       If  the  test  database does not exist, it will be created on the first
1360       run and then preserved for each subsequent run. Unless the MIGRATE test
1361       setting  is False, any unapplied migrations will also be applied to the
1362       test database before running the test suite.
1363
1364       --shuffle [SEED]
1365
1366
1367
1368       Randomizes the order of tests before running them. This can help detect
1369       tests  that  aren't properly isolated. The test order generated by this
1370       option is a deterministic function of the integer seed given.  When  no
1371       seed  is  passed, a seed is chosen randomly and printed to the console.
1372       To repeat a particular test order, pass a seed. The test orders  gener‐
1373       ated  by  this  option preserve Django's guarantees on test order. They
1374       also keep tests grouped by test case class.
1375
1376       The shuffled orderings also have a special consistency property  useful
1377       when narrowing down isolation issues. Namely, for a given seed and when
1378       running a subset of tests, the new order will be the original shuffling
1379       restricted to the smaller set. Similarly, when adding tests while keep‐
1380       ing the seed the same, the order of the original tests will be the same
1381       in the new order.
1382
1383       --reverse, -r
1384
1385       Sorts  test cases in the opposite execution order. This may help in de‐
1386       bugging the side effects of tests that aren't properly isolated. Group‐
1387       ing by test class is preserved when using this option. This can be used
1388       in conjunction with --shuffle to reverse the  order  for  a  particular
1389       seed.
1390
1391       --debug-mode
1392
1393       Sets  the  DEBUG  setting to True prior to running tests. This may help
1394       troubleshoot test failures.
1395
1396       --debug-sql, -d
1397
1398       Enables SQL logging for  failing  tests.  If  --verbosity  is  2,  then
1399       queries in passing tests are also output.
1400
1401       --parallel [N]
1402
1403       DJANGO_TEST_PROCESSES
1404
1405       Runs tests in separate parallel processes. Since modern processors have
1406       multiple cores, this allows running tests significantly faster.
1407
1408       Using --parallel without a value, or with the value auto, runs one test
1409       process  per  core  according  to  multiprocessing.cpu_count(). You can
1410       override this by passing the desired number of processes, e.g.   --par‐
1411       allel 4, or by setting the DJANGO_TEST_PROCESSES environment variable.
1412
1413       Django  distributes test cases — unittest.TestCase subclasses — to sub‐
1414       processes. If there are fewer test  cases  than  configured  processes,
1415       Django will reduce the number of processes accordingly.
1416
1417       Each process gets its own database. You must ensure that different test
1418       cases don't access the same resources. For instance,  test  cases  that
1419       touch  the filesystem should create a temporary directory for their own
1420       use.
1421
1422       NOTE:
1423          If you have test classes that cannot be run in parallel, you can use
1424          SerializeMixin  to  run  them sequentially. See Enforce running test
1425          classes sequentially.
1426
1427       This option requires the third-party tblib package  to  display  trace‐
1428       backs correctly:
1429
1430          $ python -m pip install tblib
1431
1432       This  feature isn't available on Windows. It doesn't work with the Ora‐
1433       cle database backend either.
1434
1435       If you want to use pdb while debugging tests, you must disable parallel
1436       execution  (--parallel=1). You'll see something like bdb.BdbQuit if you
1437       don't.
1438
1439       WARNING:
1440          When test parallelization is enabled and a test fails, Django may be
1441          unable  to  display the exception traceback. This can make debugging
1442          difficult. If you encounter this  problem,  run  the  affected  test
1443          without parallelization to see the traceback of the failure.
1444
1445          This is a known limitation. It arises from the need to serialize ob‐
1446          jects in order to exchange them between processes. See What  can  be
1447          pickled and unpickled? for details.
1448
1449       Support for the value auto was added.
1450
1451
1452       --tag TAGS
1453
1454       Runs  only tests marked with the specified tags.  May be specified mul‐
1455       tiple times and combined with test --exclude-tag.
1456
1457       Tests that fail to load are always considered matching.
1458
1459       In older versions, tests that failed to load did not match tags.
1460
1461
1462       --exclude-tag EXCLUDE_TAGS
1463
1464       Excludes tests marked with the specified tags.  May be specified multi‐
1465       ple times and combined with test --tag.
1466
1467       -k TEST_NAME_PATTERNS
1468
1469       Runs  test methods and classes matching test name patterns, in the same
1470       way as unittest's -k option. Can be specified multiple times.
1471
1472       --pdb
1473
1474       Spawns a pdb debugger at each test error or failure. If you have it in‐
1475       stalled, ipdb is used instead.
1476
1477       --buffer, -b
1478
1479       Discards  output (stdout and stderr) for passing tests, in the same way
1480       as unittest's --buffer option.
1481
1482       --no-faulthandler
1483
1484
1485
1486       Django automatically  calls  faulthandler.enable()  when  starting  the
1487       tests, which allows it to print a traceback if the interpreter crashes.
1488       Pass --no-faulthandler to disable this behavior.
1489
1490       --timing
1491
1492
1493
1494       Outputs timings, including database setup and total run time.
1495
1496   testserver
1497       django-admin testserver [fixture [fixture ...]]
1498
1499       Runs a Django development server (as in runserver) using data from  the
1500       given fixture(s).
1501
1502       For example, this command:
1503
1504          django-admin testserver mydata.json
1505
1506       ...would perform the following steps:
1507
1508       1. Create a test database, as described in the-test-database.
1509
1510       2. Populate  the  test  database  with fixture data from the given fix‐
1511          tures.  (For more on fixtures, see the  documentation  for  loaddata
1512          above.)
1513
1514       3. Runs  the  Django  development  server (as in runserver), pointed at
1515          this newly created test database instead of  your  production  data‐
1516          base.
1517
1518       This is useful in a number of ways:
1519
1520       • When  you're  writing  unit  tests of how your views act with certain
1521         fixture data, you can use testserver to interact with the views in  a
1522         web browser, manually.
1523
1524       • Let's say you're developing your Django application and have a "pris‐
1525         tine" copy of a database that you'd like to interact  with.  You  can
1526         dump  your  database  to  a  fixture (using the dumpdata command, ex‐
1527         plained above), then use testserver to run your web application  with
1528         that  data.  With this arrangement, you have the flexibility of mess‐
1529         ing up your data in any  way,  knowing  that  whatever  data  changes
1530         you're making are only being made to a test database.
1531
1532       Note  that  this  server  does not automatically detect changes to your
1533       Python source code  (as  runserver  does).  It  does,  however,  detect
1534       changes to templates.
1535
1536       --addrport ADDRPORT
1537
1538       Specifies a different port, or IP address and port, from the default of
1539       127.0.0.1:8000. This value follows exactly the same format  and  serves
1540       exactly the same function as the argument to the runserver command.
1541
1542       Examples:
1543
1544       To run the test server on port 7000 with fixture1 and fixture2:
1545
1546          django-admin testserver --addrport 7000 fixture1 fixture2
1547          django-admin testserver fixture1 fixture2 --addrport 7000
1548
1549       (The above statements are equivalent. We include both of them to demon‐
1550       strate that it doesn't matter whether the options come before or  after
1551       the fixture arguments.)
1552
1553       To run on 1.2.3.4:7000 with a test fixture:
1554
1555          django-admin testserver --addrport 1.2.3.4:7000 test
1556
1557       --noinput, --no-input
1558
1559       Suppresses all user prompts. A typical prompt is a warning about delet‐
1560       ing an existing test database.
1561

COMMANDS PROVIDED BY APPLICATIONS

1563       Some commands are only available when  the  django.contrib  application
1564       that  implements  them  has  been  enabled. This section describes them
1565       grouped by their application.
1566
1567   django.contrib.auth
1568   changepassword
1569       django-admin changepassword [<username>]
1570
1571       This command  is  only  available  if  Django's  authentication  system
1572       (django.contrib.auth) is installed.
1573
1574       Allows  changing a user's password. It prompts you to enter a new pass‐
1575       word twice for the given user. If the entries are identical, this imme‐
1576       diately becomes the new password. If you do not supply a user, the com‐
1577       mand will attempt to change the password  whose  username  matches  the
1578       current user.
1579
1580       --database DATABASE
1581
1582       Specifies the database to query for the user. Defaults to default.
1583
1584       Example usage:
1585
1586          django-admin changepassword ringo
1587
1588   createsuperuser
1589       django-admin createsuperuser
1590
1591       DJANGO_SUPERUSER_PASSWORD
1592
1593       This  command  is  only  available  if  Django's  authentication system
1594       (django.contrib.auth) is installed.
1595
1596       Creates a superuser account (a user who has all permissions).  This  is
1597       useful  if  you  need  to create an initial superuser account or if you
1598       need to programmatically generate superuser accounts for your site(s).
1599
1600       When run interactively, this command will prompt for a password for the
1601       new  superuser  account.  When run non-interactively, you can provide a
1602       password by setting the DJANGO_SUPERUSER_PASSWORD environment variable.
1603       Otherwise,  no password will be set, and the superuser account will not
1604       be able to log in until a password has been manually set for it.
1605
1606       In non-interactive mode, the USERNAME_FIELD and required fields (listed
1607       in    REQUIRED_FIELDS)    fall    back    to   DJANGO_SUPERUSER_<upper‐
1608       case_field_name> environment variables, unless they are overridden by a
1609       command  line argument. For example, to provide an email field, you can
1610       use DJANGO_SUPERUSER_EMAIL environment variable.
1611
1612       --noinput, --no-input
1613
1614       Suppresses all user prompts. If a suppressed prompt cannot be  resolved
1615       automatically, the command will exit with error code 1.
1616
1617       --username USERNAME
1618
1619       --email EMAIL
1620
1621       The  username  and email address for the new account can be supplied by
1622       using the --username and --email arguments on the command line. If  ei‐
1623       ther  of those is not supplied, createsuperuser will prompt for it when
1624       running interactively.
1625
1626       --database DATABASE
1627
1628       Specifies the database into which the superuser object will be saved.
1629
1630       You can subclass the management command and  override  get_input_data()
1631       if  you want to customize data input and validation. Consult the source
1632       code for details on the existing implementation and the method's param‐
1633       eters.  For example, it could be useful if you have a ForeignKey in RE‐
1634       QUIRED_FIELDS and want to allow creating an instance instead of  enter‐
1635       ing the primary key of an existing instance.
1636
1637   django.contrib.contenttypes
1638   remove_stale_contenttypes
1639       django-admin remove_stale_contenttypes
1640
1641       This   command   is   only   available  if  Django's  contenttypes  app
1642       (django.contrib.contenttypes) is installed.
1643
1644       Deletes stale content types (from deleted models) in your database. Any
1645       objects  that depend on the deleted content types will also be deleted.
1646       A list of deleted objects will be displayed  before  you  confirm  it's
1647       okay to proceed with the deletion.
1648
1649       --database DATABASE
1650
1651       Specifies the database to use. Defaults to default.
1652
1653       --include-stale-apps
1654
1655       Deletes  stale  content  types including ones from previously installed
1656       apps that have been removed from INSTALLED_APPS. Defaults to False.
1657
1658   django.contrib.gis
1659   ogrinspect
1660       This command is only available if GeoDjango (django.contrib.gis) is in‐
1661       stalled.
1662
1663       Please refer to its description in the GeoDjango documentation.
1664
1665   django.contrib.sessions
1666   clearsessions
1667       django-admin clearsessions
1668
1669       Can be run as a cron job or directly to clean out expired sessions.
1670
1671   django.contrib.sitemaps
1672   ping_google
1673       This  command  is only available if the Sitemaps framework (django.con‐
1674       trib.sitemaps) is installed.
1675
1676       Please refer to its description in the Sitemaps documentation.
1677
1678   django.contrib.staticfiles
1679   collectstatic
1680       This  command  is  only  available  if  the  static  files  application
1681       (django.contrib.staticfiles) is installed.
1682
1683       Please refer to its description in the staticfiles documentation.
1684
1685   findstatic
1686       This  command  is  only  available  if  the  static  files  application
1687       (django.contrib.staticfiles) is installed.
1688
1689       Please refer to its description in the staticfiles documentation.
1690

DEFAULT OPTIONS

1692       Although some commands may allow their own custom options,  every  com‐
1693       mand allows for the following options by default:
1694
1695       --pythonpath PYTHONPATH
1696
1697       Adds  the  given  filesystem  path to the Python import search path. If
1698       this isn't provided, django-admin will use the  PYTHONPATH  environment
1699       variable.
1700
1701       This  option is unnecessary in manage.py, because it takes care of set‐
1702       ting the Python path for you.
1703
1704       Example usage:
1705
1706          django-admin migrate --pythonpath='/home/djangoprojects/myproject'
1707
1708       --settings SETTINGS
1709
1710       Specifies the settings module to use. The settings module should be  in
1711       Python  package  syntax,  e.g. mysite.settings. If this isn't provided,
1712       django-admin will use the DJANGO_SETTINGS_MODULE environment variable.
1713
1714       This option is unnecessary in manage.py, because  it  uses  settings.py
1715       from the current project by default.
1716
1717       Example usage:
1718
1719          django-admin migrate --settings=mysite.settings
1720
1721       --traceback
1722
1723       Displays  a full stack trace when a CommandError is raised. By default,
1724       django-admin will show an error message when a CommandError occurs  and
1725       a full stack trace for any other exception.
1726
1727       This option is ignored by runserver.
1728
1729       Example usage:
1730
1731          django-admin migrate --traceback
1732
1733       --verbosity {0,1,2,3}, -v {0,1,2,3}
1734
1735       Specifies  the amount of notification and debug information that a com‐
1736       mand should print to the console.
1737
17380 means no output.
1739
17401 means normal output (default).
1741
17422 means verbose output.
1743
17443 means very verbose output.
1745
1746       This option is ignored by runserver.
1747
1748       Example usage:
1749
1750          django-admin migrate --verbosity 2
1751
1752       --no-color
1753
1754       Disables colorized command output.  Some commands format  their  output
1755       to  be colorized. For example, errors will be printed to the console in
1756       red and SQL statements will be syntax highlighted.
1757
1758       Example usage:
1759
1760          django-admin runserver --no-color
1761
1762       --force-color
1763
1764       Forces colorization of the command output if it would otherwise be dis‐
1765       abled  as  discussed  in  Syntax coloring. For example, you may want to
1766       pipe colored output to another command.
1767
1768       --skip-checks
1769
1770       Skips running system checks prior to running the command.  This  option
1771       is  only  available  if the requires_system_checks command attribute is
1772       not an empty list or tuple.
1773
1774       Example usage:
1775
1776          django-admin migrate --skip-checks
1777

EXTRA NICETIES

1779   Syntax coloring
1780       DJANGO_COLORS
1781
1782       The django-admin / manage.py commands will use pretty color-coded  out‐
1783       put  if  your  terminal  supports ANSI-colored output. It won't use the
1784       color codes if you're piping the command's output  to  another  program
1785       unless the --force-color option is used.
1786
1787   Windows support
1788       On  Windows  10,  the Windows Terminal application, VS Code, and Power‐
1789       Shell (where virtual terminal processing is enabled) allow colored out‐
1790       put, and are supported by default.
1791
1792       Under  Windows,  the legacy cmd.exe native console doesn't support ANSI
1793       escape sequences so by default there is no color output. In  this  case
1794       either of two third-party libraries are needed:
1795
1796       • Install  colorama,  a Python package that translates ANSI color codes
1797         into Windows API calls. Django commands will detect its presence  and
1798         will make use of its services to color output just like on Unix-based
1799         platforms.  colorama can be installed via pip:
1800
1801            ...\> py -m pip install colorama
1802
1803       • Install ANSICON, a third-party tool that allows  cmd.exe  to  process
1804         ANSI  color  codes. Django commands will detect its presence and will
1805         make use of its services to color  output  just  like  on  Unix-based
1806         platforms.
1807
1808       Other  modern  terminal  environments on Windows, that support terminal
1809       colors, but which  are  not  automatically  detected  as  supported  by
1810       Django, may "fake" the installation of ANSICON by setting the appropri‐
1811       ate environmental variable, ANSICON="on".
1812
1813       Updated support for syntax coloring on Windows.
1814
1815
1816   Custom colors
1817       The colors used for syntax highlighting can be customized. Django ships
1818       with three color palettes:
1819
1820dark, suited to terminals that show white text on a black background.
1821         This is the default palette.
1822
1823light, suited to terminals that show black  text  on  a  white  back‐
1824         ground.
1825
1826nocolor, which disables syntax highlighting.
1827
1828       You select a palette by setting a DJANGO_COLORS environment variable to
1829       specify the palette you want to use. For example, to specify the  light
1830       palette under a Unix or OS/X BASH shell, you would run the following at
1831       a command prompt:
1832
1833          export DJANGO_COLORS="light"
1834
1835       You can also customize the colors that are  used.  Django  specifies  a
1836       number of roles in which color is used:
1837
1838error - A major error.
1839
1840notice - A minor error.
1841
1842success - A success.
1843
1844warning - A warning.
1845
1846sql_field - The name of a model field in SQL.
1847
1848sql_coltype - The type of a model field in SQL.
1849
1850sql_keyword - An SQL keyword.
1851
1852sql_table - The name of a model in SQL.
1853
1854http_info - A 1XX HTTP Informational server response.
1855
1856http_success - A 2XX HTTP Success server response.
1857
1858http_not_modified - A 304 HTTP Not Modified server response.
1859
1860http_redirect - A 3XX HTTP Redirect server response other than 304.
1861
1862http_not_found - A 404 HTTP Not Found server response.
1863
1864http_bad_request  - A 4XX HTTP Bad Request server response other than
1865         404.
1866
1867http_server_error - A 5XX HTTP Server Error response.
1868
1869migrate_heading - A heading in a migrations management command.
1870
1871migrate_label - A migration name.
1872
1873       Each of these roles can be assigned a  specific  foreground  and  back‐
1874       ground color, from the following list:
1875
1876black
1877
1878red
1879
1880green
1881
1882yellow
1883
1884blue
1885
1886magenta
1887
1888cyan
1889
1890white
1891
1892       Each  of  these colors can then be modified by using the following dis‐
1893       play options:
1894
1895bold
1896
1897underscore
1898
1899blink
1900
1901reverse
1902
1903conceal
1904
1905       A color specification follows one of the following patterns:
1906
1907role=fg
1908
1909role=fg/bg
1910
1911role=fg,option,option
1912
1913role=fg/bg,option,option
1914
1915       where role is the name of a valid color  role,  fg  is  the  foreground
1916       color,  bg  is the background color and each option is one of the color
1917       modifying options. Multiple color specifications are then separated  by
1918       a semicolon. For example:
1919
1920          export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
1921
1922       would  specify  that errors be displayed using blinking yellow on blue,
1923       and notices displayed using magenta. All other  color  roles  would  be
1924       left uncolored.
1925
1926       Colors  can also be specified by extending a base palette. If you put a
1927       palette name in a color specification, all the colors implied  by  that
1928       palette will be loaded. So:
1929
1930          export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
1931
1932       would specify the use of all the colors in the light color palette, ex‐
1933       cept for the colors for errors and notices which would be overridden as
1934       specified.
1935
1936   Bash completion
1937       If  you use the Bash shell, consider installing the Django bash comple‐
1938       tion script, which lives in extras/django_bash_completion in the Django
1939       source distribution. It enables tab-completion of django-admin and man‐
1940       age.py commands, so you can, for instance...
1941
1942       • Type django-admin.
1943
1944       • Press [TAB] to see all available options.
1945
1946       • Type sql, then [TAB], to see all available options whose names  start
1947         with sql.
1948
1949       See  /howto/custom-management-commands  for  how  to add customized ac‐
1950       tions.
1951
1952       django.core.management.call_command(name, *args, **options)
1953
1954       To call a management command from code use call_command.
1955
1956       name   the name of the command to call or a command object. Passing the
1957              name is preferred unless the object is required for testing.
1958
1959       *args  a  list  of  arguments  accepted  by  the command. Arguments are
1960              passed to the argument parser, so you can use the same style  as
1961              you   would   on   the  command  line.  For  example,  call_com‐
1962              mand('flush', '--verbosity=0').
1963
1964       **options
1965              named options accepted on the command-line. Options  are  passed
1966              to  the  command  without  triggering the argument parser, which
1967              means you'll  need  to  pass  the  correct  type.  For  example,
1968              call_command('flush',  verbosity=0)  (zero  must  be  an integer
1969              rather than a string).
1970
1971       Examples:
1972
1973          from django.core import management
1974          from django.core.management.commands import loaddata
1975
1976          management.call_command('flush', verbosity=0, interactive=False)
1977          management.call_command('loaddata', 'test_data', verbosity=0)
1978          management.call_command(loaddata.Command(), 'test_data', verbosity=0)
1979
1980       Note that command options that take no arguments are passed as keywords
1981       with True or False, as you can see with the interactive option above.
1982
1983       Named arguments can be passed by using either one of the following syn‐
1984       taxes:
1985
1986          # Similar to the command line
1987          management.call_command('dumpdata', '--natural-foreign')
1988
1989          # Named argument similar to the command line minus the initial dashes and
1990          # with internal dashes replaced by underscores
1991          management.call_command('dumpdata', natural_foreign=True)
1992
1993          # `use_natural_foreign_keys` is the option destination variable
1994          management.call_command('dumpdata', use_natural_foreign_keys=True)
1995
1996       Some command options have different names when using call_command() in‐
1997       stead of django-admin or manage.py. For example, django-admin createsu‐
1998       peruser --no-input translates to call_command('createsuperuser', inter‐
1999       active=False).  To find what keyword argument name to use for call_com‐
2000       mand(), check the command's source code for the dest argument passed to
2001       parser.add_argument().
2002
2003       Command options which take multiple options are passed a list:
2004
2005          management.call_command('dumpdata', exclude=['contenttypes', 'auth'])
2006
2007       The  return value of the call_command() function is the same as the re‐
2008       turn value of the handle() method of the command.
2009

OUTPUT REDIRECTION

2011       Note that you can redirect standard output and  error  streams  as  all
2012       commands  support the stdout and stderr options. For example, you could
2013       write:
2014
2015          with open('/path/to/command_output', 'w') as f:
2016              management.call_command('dumpdata', stdout=f)
2017

AUTHOR

2019       Django Software Foundation
2020
2022       Django Software Foundation and contributors
2023
2024
2025
2026
20274.0                           September 20, 2021               DJANGO-ADMIN(1)
Impressum