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

COMMANDS PROVIDED BY APPLICATIONS

1511       Some commands are only available when  the  django.contrib  application
1512       that  implements  them  has  been  enabled. This section describes them
1513       grouped by their application.
1514
1515   django.contrib.auth
1516   changepassword
1517       django-admin changepassword [<username>]
1518
1519       This command  is  only  available  if  Django's  authentication  system
1520       (django.contrib.auth) is installed.
1521
1522       Allows  changing a user's password. It prompts you to enter a new pass‐
1523       word twice for the given user. If the entries are identical, this imme‐
1524       diately becomes the new password. If you do not supply a user, the com‐
1525       mand will attempt to change the password  whose  username  matches  the
1526       current user.
1527
1528       --database DATABASE
1529
1530       Specifies the database to query for the user. Defaults to default.
1531
1532       Example usage:
1533
1534          django-admin changepassword ringo
1535
1536   createsuperuser
1537       django-admin createsuperuser
1538
1539       DJANGO_SUPERUSER_PASSWORD
1540
1541       This  command  is  only  available  if  Django's  authentication system
1542       (django.contrib.auth) is installed.
1543
1544       Creates a superuser account (a user who has all permissions).  This  is
1545       useful  if  you  need  to create an initial superuser account or if you
1546       need to programmatically generate superuser accounts for your site(s).
1547
1548       When run interactively, this command will prompt for a password for the
1549       new  superuser  account.  When run non-interactively, you can provide a
1550       password by setting the DJANGO_SUPERUSER_PASSWORD environment variable.
1551       Otherwise,  no password will be set, and the superuser account will not
1552       be able to log in until a password has been manually set for it.
1553
1554       In non-interactive mode, the USERNAME_FIELD and required fields (listed
1555       in    REQUIRED_FIELDS)    fall    back    to   DJANGO_SUPERUSER_<upper‐
1556       case_field_name> environment variables, unless they are overridden by a
1557       command  line argument. For example, to provide an email field, you can
1558       use DJANGO_SUPERUSER_EMAIL environment variable.
1559
1560       Support for using DJANGO_SUPERUSER_PASSWORD  and  DJANGO_SUPERUSER_<up‐
1561       percase_field_name> environment variables was added.
1562
1563
1564       --noinput, --no-input
1565
1566       Suppresses  all user prompts. If a suppressed prompt cannot be resolved
1567       automatically, the command will exit with error code 1.
1568
1569       --username USERNAME
1570
1571       --email EMAIL
1572
1573       The username and email address for the new account can be  supplied  by
1574       using  the --username and --email arguments on the command line. If ei‐
1575       ther of those is not supplied, createsuperuser will prompt for it  when
1576       running interactively.
1577
1578       --database DATABASE
1579
1580       Specifies the database into which the superuser object will be saved.
1581
1582       You  can  subclass the management command and override get_input_data()
1583       if you want to customize data input and validation. Consult the  source
1584       code for details on the existing implementation and the method's param‐
1585       eters. For example, it could be useful if you have a ForeignKey in  RE‐
1586       QUIRED_FIELDS  and want to allow creating an instance instead of enter‐
1587       ing the primary key of an existing instance.
1588
1589   django.contrib.contenttypes
1590   remove_stale_contenttypes
1591       django-admin remove_stale_contenttypes
1592
1593       This  command  is  only  available   if   Django's   contenttypes   app
1594       (django.contrib.contenttypes) is installed.
1595
1596       Deletes stale content types (from deleted models) in your database. Any
1597       objects that depend on the deleted content types will also be  deleted.
1598       A  list  of  deleted  objects will be displayed before you confirm it's
1599       okay to proceed with the deletion.
1600
1601       --database DATABASE
1602
1603       Specifies the database to use. Defaults to default.
1604
1605       --include-stale-apps
1606
1607
1608
1609       Deletes stale content types including ones  from  previously  installed
1610       apps that have been removed from INSTALLED_APPS. Defaults to False.
1611
1612   django.contrib.gis
1613   ogrinspect
1614       This command is only available if GeoDjango (django.contrib.gis) is in‐
1615       stalled.
1616
1617       Please refer to its description in the GeoDjango documentation.
1618
1619   django.contrib.sessions
1620   clearsessions
1621       django-admin clearsessions
1622
1623       Can be run as a cron job or directly to clean out expired sessions.
1624
1625   django.contrib.sitemaps
1626   ping_google
1627       This command is only available if the Sitemaps  framework  (django.con‐
1628       trib.sitemaps) is installed.
1629
1630       Please refer to its description in the Sitemaps documentation.
1631
1632   django.contrib.staticfiles
1633   collectstatic
1634       This  command  is  only  available  if  the  static  files  application
1635       (django.contrib.staticfiles) is installed.
1636
1637       Please refer to its description in the staticfiles documentation.
1638
1639   findstatic
1640       This  command  is  only  available  if  the  static  files  application
1641       (django.contrib.staticfiles) is installed.
1642
1643       Please refer to its description in the staticfiles documentation.
1644

DEFAULT OPTIONS

1646       Although  some  commands may allow their own custom options, every com‐
1647       mand allows for the following options:
1648
1649       --pythonpath PYTHONPATH
1650
1651       Adds the given filesystem path to the Python  import  search  path.  If
1652       this  isn't  provided, django-admin will use the PYTHONPATH environment
1653       variable.
1654
1655       This option is unnecessary in manage.py, because it takes care of  set‐
1656       ting the Python path for you.
1657
1658       Example usage:
1659
1660          django-admin migrate --pythonpath='/home/djangoprojects/myproject'
1661
1662       --settings SETTINGS
1663
1664       Specifies  the settings module to use. The settings module should be in
1665       Python package syntax, e.g. mysite.settings. If  this  isn't  provided,
1666       django-admin will use the DJANGO_SETTINGS_MODULE environment variable.
1667
1668       This  option  is  unnecessary in manage.py, because it uses settings.py
1669       from the current project by default.
1670
1671       Example usage:
1672
1673          django-admin migrate --settings=mysite.settings
1674
1675       --traceback
1676
1677       Displays a full stack trace when a CommandError is raised. By  default,
1678       django-admin  will show an error message when a CommandError occurs and
1679       a full stack trace for any other exception.
1680
1681       Example usage:
1682
1683          django-admin migrate --traceback
1684
1685       --verbosity {0,1,2,3}, -v {0,1,2,3}
1686
1687       Specifies the amount of notification and debug information that a  com‐
1688       mand should print to the console.
1689
16900 means no output.
1691
16921 means normal output (default).
1693
16942 means verbose output.
1695
16963 means very verbose output.
1697
1698       Example usage:
1699
1700          django-admin migrate --verbosity 2
1701
1702       --no-color
1703
1704       Disables  colorized  command output.  Some commands format their output
1705       to be colorized. For example, errors will be printed to the console  in
1706       red and SQL statements will be syntax highlighted.
1707
1708       Example usage:
1709
1710          django-admin runserver --no-color
1711
1712       --force-color
1713
1714       Forces colorization of the command output if it would otherwise be dis‐
1715       abled as discussed in Syntax coloring. For example,  you  may  want  to
1716       pipe colored output to another command.
1717
1718       --skip-checks
1719
1720
1721
1722       Skips  running  system checks prior to running the command. This option
1723       is only available if the requires_system_checks  command  attribute  is
1724       set to True.
1725
1726       Example usage:
1727
1728          django-admin migrate --skip-checks
1729

EXTRA NICETIES

1731   Syntax coloring
1732       DJANGO_COLORS
1733
1734       The  django-admin / manage.py commands will use pretty color-coded out‐
1735       put if your terminal supports ANSI-colored output.  It  won't  use  the
1736       color  codes  if  you're piping the command's output to another program
1737       unless the --force-color option is used.
1738
1739       Under Windows, the native console doesn't support ANSI escape sequences
1740       so by default there is no color output. But you can install the ANSICON
1741       third-party tool, the Django commands will detect its presence and will
1742       make  use of its services to color output just like on Unix-based plat‐
1743       forms.
1744
1745       The colors used for syntax highlighting can be customized. Django ships
1746       with three color palettes:
1747
1748dark, suited to terminals that show white text on a black background.
1749         This is the default palette.
1750
1751light, suited to terminals that show black  text  on  a  white  back‐
1752         ground.
1753
1754nocolor, which disables syntax highlighting.
1755
1756       You select a palette by setting a DJANGO_COLORS environment variable to
1757       specify the palette you want to use. For example, to specify the  light
1758       palette under a Unix or OS/X BASH shell, you would run the following at
1759       a command prompt:
1760
1761          export DJANGO_COLORS="light"
1762
1763       You can also customize the colors that are  used.  Django  specifies  a
1764       number of roles in which color is used:
1765
1766error - A major error.
1767
1768notice - A minor error.
1769
1770success - A success.
1771
1772warning - A warning.
1773
1774sql_field - The name of a model field in SQL.
1775
1776sql_coltype - The type of a model field in SQL.
1777
1778sql_keyword - An SQL keyword.
1779
1780sql_table - The name of a model in SQL.
1781
1782http_info - A 1XX HTTP Informational server response.
1783
1784http_success - A 2XX HTTP Success server response.
1785
1786http_not_modified - A 304 HTTP Not Modified server response.
1787
1788http_redirect - A 3XX HTTP Redirect server response other than 304.
1789
1790http_not_found - A 404 HTTP Not Found server response.
1791
1792http_bad_request  - A 4XX HTTP Bad Request server response other than
1793         404.
1794
1795http_server_error - A 5XX HTTP Server Error response.
1796
1797migrate_heading - A heading in a migrations management command.
1798
1799migrate_label - A migration name.
1800
1801       Each of these roles can be assigned a  specific  foreground  and  back‐
1802       ground color, from the following list:
1803
1804black
1805
1806red
1807
1808green
1809
1810yellow
1811
1812blue
1813
1814magenta
1815
1816cyan
1817
1818white
1819
1820       Each  of  these colors can then be modified by using the following dis‐
1821       play options:
1822
1823bold
1824
1825underscore
1826
1827blink
1828
1829reverse
1830
1831conceal
1832
1833       A color specification follows one of the following patterns:
1834
1835role=fg
1836
1837role=fg/bg
1838
1839role=fg,option,option
1840
1841role=fg/bg,option,option
1842
1843       where role is the name of a valid color  role,  fg  is  the  foreground
1844       color,  bg  is the background color and each option is one of the color
1845       modifying options. Multiple color specifications are then separated  by
1846       a semicolon. For example:
1847
1848          export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
1849
1850       would  specify  that errors be displayed using blinking yellow on blue,
1851       and notices displayed using magenta. All other  color  roles  would  be
1852       left uncolored.
1853
1854       Colors  can also be specified by extending a base palette. If you put a
1855       palette name in a color specification, all the colors implied  by  that
1856       palette will be loaded. So:
1857
1858          export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
1859
1860       would specify the use of all the colors in the light color palette, ex‐
1861       cept for the colors for errors and notices which would be overridden as
1862       specified.
1863
1864   Bash completion
1865       If  you use the Bash shell, consider installing the Django bash comple‐
1866       tion script, which lives in extras/django_bash_completion in the Django
1867       source distribution. It enables tab-completion of django-admin and man‐
1868       age.py commands, so you can, for instance...
1869
1870       • Type django-admin.
1871
1872       • Press [TAB] to see all available options.
1873
1874       • Type sql, then [TAB], to see all available options whose names  start
1875         with sql.
1876
1877       See  /howto/custom-management-commands  for  how  to add customized ac‐
1878       tions.
1879
1880       django.core.management.call_command(name, *args, **options)
1881
1882       To call a management command from code use call_command.
1883
1884       name   the name of the command to call or a command object. Passing the
1885              name is preferred unless the object is required for testing.
1886
1887       *args  a  list  of  arguments  accepted  by  the command. Arguments are
1888              passed to the argument parser, so you can use the same style  as
1889              you   would   on   the  command  line.  For  example,  call_com‐
1890              mand('flush', '--verbosity=0').
1891
1892       **options
1893              named options accepted on the command-line. Options  are  passed
1894              to  the  command  without  triggering the argument parser, which
1895              means you'll  need  to  pass  the  correct  type.  For  example,
1896              call_command('flush',  verbosity=0)  (zero  must  be  an integer
1897              rather than a string).
1898
1899       Examples:
1900
1901          from django.core import management
1902          from django.core.management.commands import loaddata
1903
1904          management.call_command('flush', verbosity=0, interactive=False)
1905          management.call_command('loaddata', 'test_data', verbosity=0)
1906          management.call_command(loaddata.Command(), 'test_data', verbosity=0)
1907
1908       Note that command options that take no arguments are passed as keywords
1909       with True or False, as you can see with the interactive option above.
1910
1911       Named arguments can be passed by using either one of the following syn‐
1912       taxes:
1913
1914          # Similar to the command line
1915          management.call_command('dumpdata', '--natural-foreign')
1916
1917          # Named argument similar to the command line minus the initial dashes and
1918          # with internal dashes replaced by underscores
1919          management.call_command('dumpdata', natural_foreign=True)
1920
1921          # `use_natural_foreign_keys` is the option destination variable
1922          management.call_command('dumpdata', use_natural_foreign_keys=True)
1923
1924       Some command options have different names when using call_command() in‐
1925       stead of django-admin or manage.py. For example, django-admin createsu‐
1926       peruser --no-input translates to call_command('createsuperuser', inter‐
1927       active=False).  To find what keyword argument name to use for call_com‐
1928       mand(), check the command's source code for the dest argument passed to
1929       parser.add_argument().
1930
1931       Command options which take multiple options are passed a list:
1932
1933          management.call_command('dumpdata', exclude=['contenttypes', 'auth'])
1934
1935       The  return value of the call_command() function is the same as the re‐
1936       turn value of the handle() method of the command.
1937

OUTPUT REDIRECTION

1939       Note that you can redirect standard output and  error  streams  as  all
1940       commands  support the stdout and stderr options. For example, you could
1941       write:
1942
1943          with open('/path/to/command_output', 'w') as f:
1944              management.call_command('dumpdata', stdout=f)
1945

AUTHOR

1947       Django Software Foundation
1948
1950       Django Software Foundation and contributors
1951
1952
1953
1954
19553.1                              June 15, 2020                 DJANGO-ADMIN(1)
Impressum