1DJANGO-ADMIN(1) Django DJANGO-ADMIN(1)
2
3
4
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
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
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
667 • django for all *.py, *.html and *.txt files (default)
668
669 • djangojs 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
711 • full (the default if not given): the lines include both file name and
712 line number.
713
714 • file: the line number is omitted.
715
716 • never: 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
1228 • app_name -- the app name as passed to the command
1229
1230 • app_directory -- the full path of the newly created app
1231
1232 • camel_case_app_name -- the app name in camel case format
1233
1234 • docs_version -- the version of the documentation: 'dev' or '1.x'
1235
1236 • django_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
1297 • project_name -- the project name as passed to the command
1298
1299 • project_directory -- the full path of the newly created project
1300
1301 • secret_key -- a random key for the SECRET_KEY setting
1302
1303 • docs_version -- the version of the documentation: 'dev' or '1.x'
1304
1305 • django_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
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
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
1690 • 0 means no output.
1691
1692 • 1 means normal output (default).
1693
1694 • 2 means verbose output.
1695
1696 • 3 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
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
1748 • dark, suited to terminals that show white text on a black background.
1749 This is the default palette.
1750
1751 • light, suited to terminals that show black text on a white back‐
1752 ground.
1753
1754 • nocolor, 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
1766 • error - A major error.
1767
1768 • notice - A minor error.
1769
1770 • success - A success.
1771
1772 • warning - A warning.
1773
1774 • sql_field - The name of a model field in SQL.
1775
1776 • sql_coltype - The type of a model field in SQL.
1777
1778 • sql_keyword - An SQL keyword.
1779
1780 • sql_table - The name of a model in SQL.
1781
1782 • http_info - A 1XX HTTP Informational server response.
1783
1784 • http_success - A 2XX HTTP Success server response.
1785
1786 • http_not_modified - A 304 HTTP Not Modified server response.
1787
1788 • http_redirect - A 3XX HTTP Redirect server response other than 304.
1789
1790 • http_not_found - A 404 HTTP Not Found server response.
1791
1792 • http_bad_request - A 4XX HTTP Bad Request server response other than
1793 404.
1794
1795 • http_server_error - A 5XX HTTP Server Error response.
1796
1797 • migrate_heading - A heading in a migrations management command.
1798
1799 • migrate_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
1804 • black
1805
1806 • red
1807
1808 • green
1809
1810 • yellow
1811
1812 • blue
1813
1814 • magenta
1815
1816 • cyan
1817
1818 • white
1819
1820 Each of these colors can then be modified by using the following dis‐
1821 play options:
1822
1823 • bold
1824
1825 • underscore
1826
1827 • blink
1828
1829 • reverse
1830
1831 • conceal
1832
1833 A color specification follows one of the following patterns:
1834
1835 • role=fg
1836
1837 • role=fg/bg
1838
1839 • role=fg,option,option
1840
1841 • role=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
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
1947 Django Software Foundation
1948
1950 Django Software Foundation and contributors
1951
1952
1953
1954
19553.1 June 15, 2020 DJANGO-ADMIN(1)