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 on your path, you can find it in site-pack‐
18       ages/django/bin within your Python installation. Consider symlinking it
19       from some place on your path, such as /usr/local/bin.
20
21       For Windows users, who do not have symlinking functionality  available,
22       you  can  copy  django-admin.exe to a location on your existing path or
23       edit the PATH settings (under Settings  -  Control  Panel  -  System  -
24       Advanced - Environment...) to point to its installed location.
25
26       Generally,  when working on a single Django project, it's easier to use
27       manage.py than django-admin. If you need  to  switch  between  multiple
28       Django  settings files, use django-admin with DJANGO_SETTINGS_MODULE or
29       the --settings command line option.
30
31       The command-line examples throughout this document use django-admin  to
32       be  consistent,  but  any example can use manage.py or python -m django
33       just as well.
34

USAGE

36          $ django-admin <command> [options]
37          $ manage.py <command> [options]
38          $ python -m django <command> [options]
39
40       command should  be  one  of  the  commands  listed  in  this  document.
41       options,  which  is  optional,  should  be  zero or more of the options
42       available for the given command.
43
44   Getting runtime help
45       django-admin help
46
47       Run django-admin help to display usage information and a  list  of  the
48       commands provided by each application.
49
50       Run  django-admin  help  --commands  to display a list of all available
51       commands.
52
53       Run django-admin help <command> to display a description of  the  given
54       command and a list of its available options.
55
56   App names
57       Many commands take a list of "app names." An "app name" is the basename
58       of  the  package  containing  your  models.  For   example,   if   your
59       INSTALLED_APPS contains the string 'mysite.blog', the app name is blog.
60
61   Determining the version
62       django-admin version
63
64       Run django-admin version to display the current Django version.
65
66       The output follows the schema described in PEP 440:
67
68          1.4.dev17026
69          1.4a1
70          1.4
71
72   Displaying debug output
73       Use  --verbosity to specify the amount of notification and debug infor‐
74       mation that django-admin prints to the console.
75

AVAILABLE COMMANDS

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

COMMANDS PROVIDED BY APPLICATIONS

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

DEFAULT OPTIONS

1608       Although some commands may allow their own custom options,  every  com‐
1609       mand allows for the following options:
1610
1611       --pythonpath PYTHONPATH
1612
1613       Adds  the  given  filesystem  path to the Python import search path. If
1614       this isn't provided, django-admin will use the  PYTHONPATH  environment
1615       variable.
1616
1617       This  option is unnecessary in manage.py, because it takes care of set‐
1618       ting the Python path for you.
1619
1620       Example usage:
1621
1622          django-admin migrate --pythonpath='/home/djangoprojects/myproject'
1623
1624       --settings SETTINGS
1625
1626       Specifies the settings module to use. The settings module should be  in
1627       Python  package  syntax,  e.g. mysite.settings. If this isn't provided,
1628       django-admin will use the DJANGO_SETTINGS_MODULE environment variable.
1629
1630       This option is unnecessary in manage.py, because  it  uses  settings.py
1631       from the current project by default.
1632
1633       Example usage:
1634
1635          django-admin migrate --settings=mysite.settings
1636
1637       --traceback
1638
1639       Displays  a full stack trace when a CommandError is raised. By default,
1640       django-admin will show an error message when a CommandError occurs  and
1641       a full stack trace for any other exception.
1642
1643       Example usage:
1644
1645          django-admin migrate --traceback
1646
1647       --verbosity {0,1,2,3}, -v {0,1,2,3}
1648
1649       Specifies  the amount of notification and debug information that a com‐
1650       mand should print to the console.
1651
1652       · 0 means no output.
1653
1654       · 1 means normal output (default).
1655
1656       · 2 means verbose output.
1657
1658       · 3 means very verbose output.
1659
1660       Example usage:
1661
1662          django-admin migrate --verbosity 2
1663
1664       --no-color
1665
1666       Disables colorized command output.  Some commands format  their  output
1667       to  be colorized. For example, errors will be printed to the console in
1668       red and SQL statements will be syntax highlighted.
1669
1670       Example usage:
1671
1672          django-admin runserver --no-color
1673
1674       --force-color
1675
1676
1677
1678       Forces colorization of the command output if it would otherwise be dis‐
1679       abled  as  discussed  in  Syntax coloring. For example, you may want to
1680       pipe colored output to another command.
1681
1682       --skip-checks
1683
1684
1685
1686       Skips running system checks prior to running the command.  This  option
1687       is  only  available  if the requires_system_checks command attribute is
1688       set to True.
1689
1690       Example usage:
1691
1692          django-admin migrate --skip-checks
1693

EXTRA NICETIES

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

OUTPUT REDIRECTION

1901       Note  that  you  can  redirect standard output and error streams as all
1902       commands support the stdout and stderr options. For example, you  could
1903       write:
1904
1905          with open('/path/to/command_output', 'w') as f:
1906              management.call_command('dumpdata', stdout=f)
1907

AUTHOR

1909       Django Software Foundation
1910
1912       Django Software Foundation and contributors
1913
1914
1915
1916
19173.0                            November 18, 2019               DJANGO-ADMIN(1)
Impressum