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 manage.py does the same thing as django-admin but takes care of a few
13 things for you:
14
15 · It puts your project’s package on sys.path.
16
17 · It sets the DJANGO_SETTINGS_MODULE environment variable so that it
18 points to your project’s settings.py file.
19
20 The django-admin script should be on your system path if you installed
21 Django via its setup.py utility. If it’s not on your path, you can find
22 it in site-packages/django/bin within your Python installation. Con‐
23 sider symlinking it from some place on your path, such as
24 /usr/local/bin.
25
26 For Windows users, who do not have symlinking functionality available,
27 you can copy django-admin.exe to a location on your existing path or
28 edit the PATH settings (under Settings - Control Panel - System -
29 Advanced - Environment...) to point to its installed location.
30
31 Generally, when working on a single Django project, it’s easier to use
32 manage.py than django-admin. If you need to switch between multiple
33 Django settings files, use django-admin with DJANGO_SETTINGS_MODULE or
34 the --settings command line option.
35
36 The command-line examples throughout this document use django-admin to
37 be consistent, but any example can use manage.py or python -m django
38 just as well.
39
41 $ django-admin <command> [options]
42 $ manage.py <command> [options]
43 $ python -m django <command> [options]
44
45 command should be one of the commands listed in this document.
46 options, which is optional, should be zero or more of the options
47 available for the given command.
48
49 Getting runtime help
50 django-admin help
51
52 Run django-admin help to display usage information and a list of the
53 commands provided by each application.
54
55 Run django-admin help --commands to display a list of all available
56 commands.
57
58 Run django-admin help <command> to display a description of the given
59 command and a list of its available options.
60
61 App names
62 Many commands take a list of “app names.” An “app name” is the basename
63 of the package containing your models. For example, if your
64 INSTALLED_APPS contains the string 'mysite.blog', the app name is blog.
65
66 Determining the version
67 django-admin version
68
69 Run django-admin version to display the current Django version.
70
71 The output follows the schema described in PEP 440:
72
73 1.4.dev17026
74 1.4a1
75 1.4
76
77 Displaying debug output
78 Use --verbosity to specify the amount of notification and debug infor‐
79 mation that django-admin prints to the console.
80
82 check
83 django-admin check [app_label [app_label ...]]
84
85 Uses the system check framework to inspect the entire Django project
86 for common problems.
87
88 By default, all apps will be checked. You can check a subset of apps by
89 providing a list of app labels as arguments:
90
91 django-admin check auth admin myapp
92
93 If you do not specify any app, all apps will be checked.
94
95 --tag TAGS, -t TAGS
96
97 The system check framework performs many different types of checks that
98 are categorized with tags. You can use these tags to restrict the
99 checks performed to just those in a particular category. For example,
100 to perform only models and compatibility checks, run:
101
102 django-admin check --tag models --tag compatibility
103
104 --list-tags
105
106 Lists all available tags.
107
108 --deploy
109
110 Activates some additional checks that are only relevant in a deployment
111 setting.
112
113 You can use this option in your local development environment, but
114 since your local development settings module may not have many of your
115 production settings, you will probably want to point the check command
116 at a different settings module, either by setting the DJANGO_SET‐
117 TINGS_MODULE environment variable, or by passing the --settings option:
118
119 django-admin check --deploy --settings=production_settings
120
121 Or you could run it directly on a production or staging deployment to
122 verify that the correct settings are in use (omitting --settings). You
123 could even make it part of your integration test suite.
124
125 --fail-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}
126
127 Specifies the message level that will cause the command to exit with a
128 non-zero status. Default is ERROR.
129
130 compilemessages
131 django-admin compilemessages
132
133 Compiles .po files created by makemessages to .mo files for use with
134 the built-in gettext support. See /topics/i18n/index.
135
136 --locale LOCALE, -l LOCALE
137
138 Specifies the locale(s) to process. If not provided, all locales are
139 processed.
140
141 --exclude EXCLUDE, -x EXCLUDE
142
143 Specifies the locale(s) to exclude from processing. If not provided, no
144 locales are excluded.
145
146 --use-fuzzy, -f
147
148 Includes fuzzy translations into compiled files.
149
150 Example usage:
151
152 django-admin compilemessages --locale=pt_BR
153 django-admin compilemessages --locale=pt_BR --locale=fr -f
154 django-admin compilemessages -l pt_BR
155 django-admin compilemessages -l pt_BR -l fr --use-fuzzy
156 django-admin compilemessages --exclude=pt_BR
157 django-admin compilemessages --exclude=pt_BR --exclude=fr
158 django-admin compilemessages -x pt_BR
159 django-admin compilemessages -x pt_BR -x fr
160
161 createcachetable
162 django-admin createcachetable
163
164 Creates the cache tables for use with the database cache backend using
165 the information from your settings file. See /topics/cache for more
166 information.
167
168 --database DATABASE
169
170 Specifies the database in which the cache table(s) will be created.
171 Defaults to default.
172
173 --dry-run
174
175 Prints the SQL that would be run without actually running it, so you
176 can customize it or use the migrations framework.
177
178 dbshell
179 django-admin dbshell
180
181 Runs the command-line client for the database engine specified in your
182 ENGINE setting, with the connection parameters specified in your USER,
183 PASSWORD, etc., settings.
184
185 · For PostgreSQL, this runs the psql command-line client.
186
187 · For MySQL, this runs the mysql command-line client.
188
189 · For SQLite, this runs the sqlite3 command-line client.
190
191 · For Oracle, this runs the sqlplus command-line client.
192
193 This command assumes the programs are on your PATH so that a simple
194 call to the program name (psql, mysql, sqlite3, sqlplus) will find the
195 program in the right place. There’s no way to specify the location of
196 the program manually.
197
198 --database DATABASE
199
200 Specifies the database onto which to open a shell. Defaults to default.
201
202 diffsettings
203 django-admin diffsettings
204
205 Displays differences between the current settings file and Django’s
206 default settings (or another settings file specified by --default).
207
208 Settings that don’t appear in the defaults are followed by "###". For
209 example, the default settings don’t define ROOT_URLCONF, so ROOT_URL‐
210 CONF is followed by "###" in the output of diffsettings.
211
212 --all
213
214 Displays all settings, even if they have Django’s default value. Such
215 settings are prefixed by "###".
216
217 --default MODULE
218
219
220
221 The settings module to compare the current settings against. Leave
222 empty to compare against Django’s default settings.
223
224 --output {hash,unified}
225
226
227
228 Specifies the output format. Available values are hash and unified.
229 hash is the default mode that displays the output that’s described
230 above. unified displays the output similar to diff -u. Default set‐
231 tings are prefixed with a minus sign, followed by the changed setting
232 prefixed with a plus sign.
233
234 dumpdata
235 django-admin dumpdata [app_label[.ModelName] [app_label[.ModelName]
236 ...]]
237
238 Outputs to standard output all data in the database associated with the
239 named application(s).
240
241 If no application name is provided, all installed applications will be
242 dumped.
243
244 The output of dumpdata can be used as input for loaddata.
245
246 Note that dumpdata uses the default manager on the model for selecting
247 the records to dump. If you’re using a custom manager as the default
248 manager and it filters some of the available records, not all of the
249 objects will be dumped.
250
251 --all, -a
252
253 Uses Django’s base manager, dumping records which might otherwise be
254 filtered or modified by a custom manager.
255
256 --format FORMAT
257
258 Specifies the serialization format of the output. Defaults to JSON.
259 Supported formats are listed in serialization-formats.
260
261 --indent INDENT
262
263 Specifies the number of indentation spaces to use in the output.
264 Defaults to None which displays all data on single line.
265
266 --exclude EXCLUDE, -e EXCLUDE
267
268 Prevents specific applications or models (specified in the form of
269 app_label.ModelName) from being dumped. If you specify a model name,
270 the output will be restricted to that model, rather than the entire
271 application. You can also mix application names and model names.
272
273 If you want to exclude multiple applications, pass --exclude more than
274 once:
275
276 django-admin dumpdata --exclude=auth --exclude=contenttypes
277
278 --database DATABASE
279
280 Specifies the database from which data will be dumped. Defaults to
281 default.
282
283 --natural-foreign
284
285 Uses the natural_key() model method to serialize any foreign key and
286 many-to-many relationship to objects of the type that defines the
287 method. If you’re dumping contrib.auth Permission objects or con‐
288 trib.contenttypes ContentType objects, you should probably use this
289 flag. See the natural keys documentation for more details on this and
290 the next option.
291
292 --natural-primary
293
294 Omits the primary key in the serialized data of this object since it
295 can be calculated during deserialization.
296
297 --pks PRIMARY_KEYS
298
299 Outputs only the objects specified by a comma separated list of primary
300 keys. This is only available when dumping one model. By default, all
301 the records of the model are output.
302
303 --output OUTPUT, -o OUTPUT
304
305 Specifies a file to write the serialized data to. By default, the data
306 goes to standard output.
307
308 When this option is set and --verbosity is greater than 0 (the
309 default), a progress bar is shown in the terminal.
310
311 flush
312 django-admin flush
313
314 Removes all data from the database and re-executes any post-synchro‐
315 nization handlers. The table of which migrations have been applied is
316 not cleared.
317
318 If you would rather start from an empty database and re-run all migra‐
319 tions, you should drop and recreate the database and then run migrate
320 instead.
321
322 --noinput, --no-input
323
324 Suppresses all user prompts.
325
326 --database DATABASE
327
328 Specifies the database to flush. Defaults to default.
329
330 inspectdb
331 django-admin inspectdb [table [table ...]]
332
333 Introspects the database tables in the database pointed-to by the NAME
334 setting and outputs a Django model module (a models.py file) to stan‐
335 dard output. You may choose what tables to inspect by passing their
336 names as arguments.
337
338 Use this if you have a legacy database with which you’d like to use
339 Django. The script will inspect the database and create a model for
340 each table within it.
341
342 As you might expect, the created models will have an attribute for
343 every field in the table. Note that inspectdb has a few special cases
344 in its field-name output:
345
346 · If inspectdb cannot map a column’s type to a model field type, it’ll
347 use TextField and will insert the Python comment 'This field type is
348 a guess.' next to the field in the generated model. The recognized
349 fields may depend on apps listed in INSTALLED_APPS. For example,
350 django.contrib.postgres adds recognition for several PostgreSQL-spe‐
351 cific field types.
352
353 · If the database column name is a Python reserved word (such as
354 'pass', 'class' or 'for'), inspectdb will append '_field' to the
355 attribute name. For example, if a table has a column 'for', the gen‐
356 erated model will have a field 'for_field', with the db_column
357 attribute set to 'for'. inspectdb will insert the Python comment
358 'Field renamed because it was a Python reserved word.' next to the
359 field.
360
361 This feature is meant as a shortcut, not as definitive model genera‐
362 tion. After you run it, you’ll want to look over the generated models
363 yourself to make customizations. In particular, you’ll need to rear‐
364 range models’ order, so that models that refer to other models are
365 ordered properly.
366
367 Primary keys are automatically introspected for PostgreSQL, MySQL and
368 SQLite, in which case Django puts in the primary_key=True where needed.
369
370 inspectdb works with PostgreSQL, MySQL and SQLite. Foreign-key detec‐
371 tion only works in PostgreSQL and with certain types of MySQL tables.
372
373 Django doesn’t create database defaults when a default is specified on
374 a model field. Similarly, database defaults aren’t translated to model
375 field defaults or detected in any fashion by inspectdb.
376
377 By default, inspectdb creates unmanaged models. That is, managed =
378 False in the model’s Meta class tells Django not to manage each table’s
379 creation, modification, and deletion. If you do want to allow Django to
380 manage the table’s lifecycle, you’ll need to change the managed option
381 to True (or simply remove it because True is its default value).
382
383 --database DATABASE
384
385 Specifies the database to introspect. Defaults to default.
386
387 loaddata
388 django-admin loaddata fixture [fixture ...]
389
390 Searches for and loads the contents of the named fixture into the data‐
391 base.
392
393 --database DATABASE
394
395 Specifies the database into which the data will be loaded. Defaults to
396 default.
397
398 --ignorenonexistent, -i
399
400 Ignores fields and models that may have been removed since the fixture
401 was originally generated.
402
403 --app APP_LABEL
404
405 Specifies a single app to look for fixtures in rather than looking in
406 all apps.
407
408 --format FORMAT
409
410
411
412 Specifies the serialization format (e.g., json or xml) for fixtures
413 read from stdin.
414
415 --exclude EXCLUDE, -e EXCLUDE
416
417
418
419 Excludes loading the fixtures from the given applications and/or models
420 (in the form of app_label or app_label.ModelName). Use the option mul‐
421 tiple times to exclude more than one app or model.
422
423 What’s a “fixture”?
424 A fixture is a collection of files that contain the serialized contents
425 of the database. Each fixture has a unique name, and the files that
426 comprise the fixture can be distributed over multiple directories, in
427 multiple applications.
428
429 Django will search in three locations for fixtures:
430
431 1. In the fixtures directory of every installed application
432
433 2. In any directory named in the FIXTURE_DIRS setting
434
435 3. In the literal path named by the fixture
436
437 Django will load any and all fixtures it finds in these locations that
438 match the provided fixture names.
439
440 If the named fixture has a file extension, only fixtures of that type
441 will be loaded. For example:
442
443 django-admin loaddata mydata.json
444
445 would only load JSON fixtures called mydata. The fixture extension must
446 correspond to the registered name of a serializer (e.g., json or xml).
447
448 If you omit the extensions, Django will search all available fixture
449 types for a matching fixture. For example:
450
451 django-admin loaddata mydata
452
453 would look for any fixture of any fixture type called mydata. If a fix‐
454 ture directory contained mydata.json, that fixture would be loaded as a
455 JSON fixture.
456
457 The fixtures that are named can include directory components. These
458 directories will be included in the search path. For example:
459
460 django-admin loaddata foo/bar/mydata.json
461
462 would search <app_label>/fixtures/foo/bar/mydata.json for each
463 installed application, <dirname>/foo/bar/mydata.json for each direc‐
464 tory in FIXTURE_DIRS, and the literal path foo/bar/mydata.json.
465
466 When fixture files are processed, the data is saved to the database as
467 is. Model defined save() methods are not called, and any pre_save or
468 post_save signals will be called with raw=True since the instance only
469 contains attributes that are local to the model. You may, for example,
470 want to disable handlers that access related fields that aren’t present
471 during fixture loading and would otherwise raise an exception:
472
473 from django.db.models.signals import post_save
474 from .models import MyModel
475
476 def my_handler(**kwargs):
477 # disable the handler during fixture loading
478 if kwargs['raw']:
479 return
480 ...
481
482 post_save.connect(my_handler, sender=MyModel)
483
484 You could also write a simple decorator to encapsulate this logic:
485
486 from functools import wraps
487
488 def disable_for_loaddata(signal_handler):
489 """
490 Decorator that turns off signal handlers when loading fixture data.
491 """
492 @wraps(signal_handler)
493 def wrapper(*args, **kwargs):
494 if kwargs['raw']:
495 return
496 signal_handler(*args, **kwargs)
497 return wrapper
498
499 @disable_for_loaddata
500 def my_handler(**kwargs):
501 ...
502
503 Just be aware that this logic will disable the signals whenever fix‐
504 tures are deserialized, not just during loaddata.
505
506 Note that the order in which fixture files are processed is undefined.
507 However, all fixture data is installed as a single transaction, so data
508 in one fixture can reference data in another fixture. If the database
509 backend supports row-level constraints, these constraints will be
510 checked at the end of the transaction.
511
512 The dumpdata command can be used to generate input for loaddata.
513
514 Compressed fixtures
515 Fixtures may be compressed in zip, gz, or bz2 format. For example:
516
517 django-admin loaddata mydata.json
518
519 would look for any of mydata.json, mydata.json.zip, mydata.json.gz, or
520 mydata.json.bz2. The first file contained within a zip-compressed ar‐
521 chive is used.
522
523 Note that if two fixtures with the same name but different fixture type
524 are discovered (for example, if mydata.json and mydata.xml.gz were
525 found in the same fixture directory), fixture installation will be
526 aborted, and any data installed in the call to loaddata will be removed
527 from the database.
528
529 MySQL with MyISAM and fixtures
530
531 The MyISAM storage engine of MySQL doesn’t support transac‐
532 tions or constraints, so if you use MyISAM, you won’t get
533 validation of fixture data, or a rollback if multiple trans‐
534 action files are found.
535
536 Database-specific fixtures
537 If you’re in a multi-database setup, you might have fixture data that
538 you want to load onto one database, but not onto another. In this situ‐
539 ation, you can add a database identifier into the names of your fix‐
540 tures.
541
542 For example, if your DATABASES setting has a ‘master’ database defined,
543 name the fixture mydata.master.json or mydata.master.json.gz and the
544 fixture will only be loaded when you specify you want to load data into
545 the master database.
546
547 Loading fixtures from stdin
548 You can use a dash as the fixture name to load input from sys.stdin.
549 For example:
550
551 django-admin loaddata --format=json -
552
553 When reading from stdin, the --format option is required to specify the
554 serialization format of the input (e.g., json or xml).
555
556 Loading from stdin is useful with standard input and output redirec‐
557 tions. For example:
558
559 django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -
560
561 makemessages
562 django-admin makemessages
563
564 Runs over the entire source tree of the current directory and pulls out
565 all strings marked for translation. It creates (or updates) a message
566 file in the conf/locale (in the Django tree) or locale (for project and
567 application) directory. After making changes to the messages files you
568 need to compile them with compilemessages for use with the builtin get‐
569 text support. See the i18n documentation for details.
570
571 This command doesn’t require configured settings. However, when set‐
572 tings aren’t configured, the command can’t ignore the MEDIA_ROOT and
573 STATIC_ROOT directories or include LOCALE_PATHS. It will also write
574 files in UTF-8 rather than in FILE_CHARSET.
575
576 --all, -a
577
578 Updates the message files for all available languages.
579
580 --extension EXTENSIONS, -e EXTENSIONS
581
582 Specifies a list of file extensions to examine (default: html, txt, py
583 or js if --domain is js).
584
585 Example usage:
586
587 django-admin makemessages --locale=de --extension xhtml
588
589 Separate multiple extensions with commas or use -e or --extension mul‐
590 tiple times:
591
592 django-admin makemessages --locale=de --extension=html,txt --extension xml
593
594 --locale LOCALE, -l LOCALE
595
596 Specifies the locale(s) to process.
597
598 --exclude EXCLUDE, -x EXCLUDE
599
600 Specifies the locale(s) to exclude from processing. If not provided, no
601 locales are excluded.
602
603 Example usage:
604
605 django-admin makemessages --locale=pt_BR
606 django-admin makemessages --locale=pt_BR --locale=fr
607 django-admin makemessages -l pt_BR
608 django-admin makemessages -l pt_BR -l fr
609 django-admin makemessages --exclude=pt_BR
610 django-admin makemessages --exclude=pt_BR --exclude=fr
611 django-admin makemessages -x pt_BR
612 django-admin makemessages -x pt_BR -x fr
613
614 --domain DOMAIN, -d DOMAIN
615
616 Specifies the domain of the messages files. Supported options are:
617
618 · django for all *.py, *.html and *.txt files (default)
619
620 · djangojs for *.js files
621
622 --symlinks, -s
623
624 Follows symlinks to directories when looking for new translation
625 strings.
626
627 Example usage:
628
629 django-admin makemessages --locale=de --symlinks
630
631 --ignore PATTERN, -i PATTERN
632
633 Ignores files or directories matching the given glob-style pattern. Use
634 multiple times to ignore more.
635
636 These patterns are used by default: 'CVS', '.*', '*~', '*.pyc'.
637
638 Example usage:
639
640 django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html
641
642 --no-default-ignore
643
644 Disables the default values of --ignore.
645
646 --no-wrap
647
648 Disables breaking long message lines into several lines in language
649 files.
650
651 --no-location
652
653 Suppresses writing ‘#: filename:line’ comment lines in language files.
654 Using this option makes it harder for technically skilled translators
655 to understand each message’s context.
656
657 --add-location [{full,file,never}]
658
659
660
661 Controls #: filename:line comment lines in language files. If the
662 option is:
663
664 · full (the default if not given): the lines include both file name and
665 line number.
666
667 · file: the line number is omitted.
668
669 · never: the lines are suppressed (same as --no-location).
670
671 Requires gettext 0.19 or newer.
672
673 --keep-pot
674
675 Prevents deleting the temporary .pot files generated before creating
676 the .po file. This is useful for debugging errors which may prevent the
677 final language files from being created.
678
679 SEE ALSO:
680 See customizing-makemessages for instructions on how to customize
681 the keywords that makemessages passes to xgettext.
682
683 makemigrations
684 django-admin makemigrations [app_label [app_label ...]]
685
686 Creates new migrations based on the changes detected to your models.
687 Migrations, their relationship with apps and more are covered in depth
688 in the migrations documentation.
689
690 Providing one or more app names as arguments will limit the migrations
691 created to the app(s) specified and any dependencies needed (the table
692 at the other end of a ForeignKey, for example).
693
694 To add migrations to an app that doesn’t have a migrations directory,
695 run makemigrations with the app’s app_label.
696
697 --noinput, --no-input
698
699 Suppresses all user prompts. If a suppressed prompt cannot be resolved
700 automatically, the command will exit with error code 3.
701
702 --empty
703
704 Outputs an empty migration for the specified apps, for manual editing.
705 This is for advanced users and should not be used unless you are famil‐
706 iar with the migration format, migration operations, and the dependen‐
707 cies between your migrations.
708
709 --dry-run
710
711 Shows what migrations would be made without actually writing any migra‐
712 tions files to disk. Using this option along with --verbosity 3 will
713 also show the complete migrations files that would be written.
714
715 --merge
716
717 Enables fixing of migration conflicts.
718
719 --name NAME, -n NAME
720
721 Allows naming the generated migration(s) instead of using a generated
722 name.
723
724 Makes makemigrations exit with error code 1 when no migrations are cre‐
725 ated (or would have been created, if combined with --dry-run).
726
727 --check
728
729 Makes makemigrations exit with a non-zero status when model changes
730 without migrations are detected.
731
732 migrate
733 django-admin migrate [app_label] [migration_name]
734
735 Synchronizes the database state with the current set of models and
736 migrations. Migrations, their relationship with apps and more are cov‐
737 ered in depth in the migrations documentation.
738
739 The behavior of this command changes depending on the arguments pro‐
740 vided:
741
742 · No arguments: All apps have all of their migrations run.
743
744 · <app_label>: The specified app has its migrations run, up to the most
745 recent migration. This may involve running other apps’ migrations
746 too, due to dependencies.
747
748 · <app_label> <migrationname>: Brings the database schema to a state
749 where the named migration is applied, but no later migrations in the
750 same app are applied. This may involve unapplying migrations if you
751 have previously migrated past the named migration. Use the name zero
752 to unapply all migrations for an app.
753
754 --database DATABASE
755
756 Specifies the database to migrate. Defaults to default.
757
758 --fake
759
760 Tells Django to mark the migrations as having been applied or unap‐
761 plied, but without actually running the SQL to change your database
762 schema.
763
764 This is intended for advanced users to manipulate the current migration
765 state directly if they’re manually applying changes; be warned that
766 using --fake runs the risk of putting the migration state table into a
767 state where manual recovery will be needed to make migrations run cor‐
768 rectly.
769
770 --fake-initial
771
772 Allows Django to skip an app’s initial migration if all database tables
773 with the names of all models created by all CreateModel operations in
774 that migration already exist. This option is intended for use when
775 first running migrations against a database that preexisted the use of
776 migrations. This option does not, however, check for matching database
777 schema beyond matching table names and so is only safe to use if you
778 are confident that your existing schema matches what is recorded in
779 your initial migration.
780
781 --run-syncdb
782
783 Allows creating tables for apps without migrations. While this isn’t
784 recommended, the migrations framework is sometimes too slow on large
785 projects with hundreds of models.
786
787 --noinput, --no-input
788
789 Suppresses all user prompts. An example prompt is asking about removing
790 stale content types.
791
792 runserver
793 django-admin runserver [addrport]
794
795 Starts a lightweight development Web server on the local machine. By
796 default, the server runs on port 8000 on the IP address 127.0.0.1. You
797 can pass in an IP address and port number explicitly.
798
799 If you run this script as a user with normal privileges (recommended),
800 you might not have access to start a port on a low port number. Low
801 port numbers are reserved for the superuser (root).
802
803 This server uses the WSGI application object specified by the
804 WSGI_APPLICATION setting.
805
806 DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through
807 security audits or performance tests. (And that’s how it’s gonna stay.
808 We’re in the business of making Web frameworks, not Web servers, so
809 improving this server to be able to handle a production environment is
810 outside the scope of Django.)
811
812 The development server automatically reloads Python code for each
813 request, as needed. You don’t need to restart the server for code
814 changes to take effect. However, some actions like adding files don’t
815 trigger a restart, so you’ll have to restart the server in these cases.
816
817 If you are using Linux and install pyinotify, kernel signals will be
818 used to autoreload the server (rather than polling file modification
819 timestamps each second). This offers better scaling to large projects,
820 reduction in response time to code modification, more robust change
821 detection, and battery usage reduction.
822
823 When you start the server, and each time you change Python code while
824 the server is running, the system check framework will check your
825 entire Django project for some common errors (see the check command).
826 If any errors are found, they will be printed to standard output.
827
828 You can run as many concurrent servers as you want, as long as they’re
829 on separate ports. Just execute django-admin runserver more than once.
830
831 Note that the default IP address, 127.0.0.1, is not accessible from
832 other machines on your network. To make your development server view‐
833 able to other machines on the network, use its own IP address (e.g.
834 192.168.2.1) or 0.0.0.0 or :: (with IPv6 enabled).
835
836 You can provide an IPv6 address surrounded by brackets (e.g.
837 [200a::1]:8000). This will automatically enable IPv6 support.
838
839 A hostname containing ASCII-only characters can also be used.
840
841 If the staticfiles contrib app is enabled (default in new projects) the
842 runserver command will be overridden with its own runserver command.
843
844 Logging of each request and response of the server is sent to the
845 django-server-logger logger.
846
847 --noreload
848
849 Disables the auto-reloader. This means any Python code changes you make
850 while the server is running will not take effect if the particular
851 Python modules have already been loaded into memory.
852
853 --nothreading
854
855 Disables use of threading in the development server. The server is mul‐
856 tithreaded by default.
857
858 --ipv6, -6
859
860 Uses IPv6 for the development server. This changes the default IP
861 address from 127.0.0.1 to ::1.
862
863 Examples of using different ports and addresses
864 Port 8000 on IP address 127.0.0.1:
865
866 django-admin runserver
867
868 Port 8000 on IP address 1.2.3.4:
869
870 django-admin runserver 1.2.3.4:8000
871
872 Port 7000 on IP address 127.0.0.1:
873
874 django-admin runserver 7000
875
876 Port 7000 on IP address 1.2.3.4:
877
878 django-admin runserver 1.2.3.4:7000
879
880 Port 8000 on IPv6 address ::1:
881
882 django-admin runserver -6
883
884 Port 7000 on IPv6 address ::1:
885
886 django-admin runserver -6 7000
887
888 Port 7000 on IPv6 address 2001:0db8:1234:5678::9:
889
890 django-admin runserver [2001:0db8:1234:5678::9]:7000
891
892 Port 8000 on IPv4 address of host localhost:
893
894 django-admin runserver localhost:8000
895
896 Port 8000 on IPv6 address of host localhost:
897
898 django-admin runserver -6 localhost:8000
899
900 Serving static files with the development server
901 By default, the development server doesn’t serve any static files for
902 your site (such as CSS files, images, things under MEDIA_URL and so
903 forth). If you want to configure Django to serve static media, read
904 /howto/static-files/index.
905
906 sendtestemail
907 django-admin sendtestemail [email [email ...]]
908
909 Sends a test email (to confirm email sending through Django is working)
910 to the recipient(s) specified. For example:
911
912 django-admin sendtestemail foo@example.com bar@example.com
913
914 There are a couple of options, and you may use any combination of them
915 together:
916
917 --managers
918
919 Mails the email addresses specified in MANAGERS using mail_managers().
920
921 --admins
922
923 Mails the email addresses specified in ADMINS using mail_admins().
924
925 shell
926 django-admin shell
927
928 Starts the Python interactive interpreter.
929
930 --interface {ipython,bpython,python}, -i {ipython,bpython,python}
931
932 Specifies the shell to use. By default, Django will use IPython or
933 bpython if either is installed. If both are installed, specify which
934 one you want like so:
935
936 IPython:
937
938 django-admin shell -i ipython
939
940 bpython:
941
942 django-admin shell -i bpython
943
944 If you have a “rich” shell installed but want to force use of the
945 “plain” Python interpreter, use python as the interface name, like so:
946
947 django-admin shell -i python
948
949 --nostartup
950
951 Disables reading the startup script for the “plain” Python interpreter.
952 By default, the script pointed to by the PYTHONSTARTUP environment
953 variable or the ~/.pythonrc.py script is read.
954
955 --command COMMAND, -c COMMAND
956
957 Lets you pass a command as a string to execute it as Django, like so:
958
959 django-admin shell --command="import django; print(django.__version__)"
960
961 You can also pass code in on standard input to execute it. For example:
962
963 $ django-admin shell <<EOF
964 > import django
965 > print(django.__version__)
966 > EOF
967
968 On Windows, the REPL is output due to implementation limits of
969 select.select() on that platform.
970
971 In older versions, the REPL is also output on UNIX systems.
972
973
974 showmigrations
975 django-admin showmigrations [app_label [app_label ...]]
976
977 Shows all migrations in a project. You can choose from one of two for‐
978 mats:
979
980 --list, -l
981
982 Lists all of the apps Django knows about, the migrations available for
983 each app, and whether or not each migration is applied (marked by an
984 [X] next to the migration name).
985
986 Apps without migrations are also listed, but have (no migrations)
987 printed under them.
988
989 This is the default output format.
990
991 --plan, -p
992
993 Shows the migration plan Django will follow to apply migrations. Like
994 --list, applied migrations are marked by an [X]. For a --verbosity of 2
995 and above, all dependencies of a migration will also be shown.
996
997 app_labels arguments limit the output, however, dependencies of pro‐
998 vided apps may also be included.
999
1000 In older versions, showmigrations --plan ignores app labels.
1001
1002
1003 --database DATABASE
1004
1005 Specifies the database to examine. Defaults to default.
1006
1007 sqlflush
1008 django-admin sqlflush
1009
1010 Prints the SQL statements that would be executed for the flush command.
1011
1012 --database DATABASE
1013
1014 Specifies the database for which to print the SQL. Defaults to default.
1015
1016 sqlmigrate
1017 django-admin sqlmigrate app_label migration_name
1018
1019 Prints the SQL for the named migration. This requires an active data‐
1020 base connection, which it will use to resolve constraint names; this
1021 means you must generate the SQL against a copy of the database you wish
1022 to later apply it on.
1023
1024 Note that sqlmigrate doesn’t colorize its output.
1025
1026 --backwards
1027
1028 Generates the SQL for unapplying the migration. By default, the SQL
1029 created is for running the migration in the forwards direction.
1030
1031 --database DATABASE
1032
1033 Specifies the database for which to generate the SQL. Defaults to
1034 default.
1035
1036 sqlsequencereset
1037 django-admin sqlsequencereset app_label [app_label ...]
1038
1039 Prints the SQL statements for resetting sequences for the given app
1040 name(s).
1041
1042 Sequences are indexes used by some database engines to track the next
1043 available number for automatically incremented fields.
1044
1045 Use this command to generate SQL which will fix cases where a sequence
1046 is out of sync with its automatically incremented field data.
1047
1048 --database DATABASE
1049
1050 Specifies the database for which to print the SQL. Defaults to default.
1051
1052 squashmigrations
1053 django-admin squashmigrations app_label [start_migration_name] migra‐
1054 tion_name
1055
1056 Squashes the migrations for app_label up to and including migra‐
1057 tion_name down into fewer migrations, if possible. The resulting
1058 squashed migrations can live alongside the unsquashed ones safely. For
1059 more information, please read migration-squashing.
1060
1061 When start_migration_name is given, Django will only include migrations
1062 starting from and including this migration. This helps to mitigate the
1063 squashing limitation of RunPython and django.db.migrations.opera‐
1064 tions.RunSQL migration operations.
1065
1066 --no-optimize
1067
1068 Disables the optimizer when generating a squashed migration. By
1069 default, Django will try to optimize the operations in your migrations
1070 to reduce the size of the resulting file. Use this option if this
1071 process is failing or creating incorrect migrations, though please also
1072 file a Django bug report about the behavior, as optimization is meant
1073 to be safe.
1074
1075 --noinput, --no-input
1076
1077 Suppresses all user prompts.
1078
1079 --squashed-name SQUASHED_NAME
1080
1081
1082
1083 Sets the name of the squashed migration. When omitted, the name is
1084 based on the first and last migration, with _squashed_ in between.
1085
1086 startapp
1087 django-admin startapp name [directory]
1088
1089 Creates a Django app directory structure for the given app name in the
1090 current directory or the given destination.
1091
1092 By default the directory created contains a models.py file and other
1093 app template files. (See the source for more details.) If only the app
1094 name is given, the app directory will be created in the current working
1095 directory.
1096
1097 If the optional destination is provided, Django will use that existing
1098 directory rather than creating a new one. You can use ‘.’ to denote the
1099 current working directory.
1100
1101 For example:
1102
1103 django-admin startapp myapp /Users/jezdez/Code/myapp
1104
1105 --template TEMPLATE
1106
1107 Provides the path to a directory with a custom app template file or a
1108 path to a compressed file (.tar.gz, .tar.bz2, .tgz, .tbz, .zip) con‐
1109 taining the app template files.
1110
1111 For example, this would look for an app template in the given directory
1112 when creating the myapp app:
1113
1114 django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp
1115
1116 Django will also accept URLs (http, https, ftp) to compressed archives
1117 with the app template files, downloading and extracting them on the
1118 fly.
1119
1120 For example, taking advantage of GitHub’s feature to expose reposito‐
1121 ries as zip files, you can use a URL like:
1122
1123 django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip myapp
1124
1125 --extension EXTENSIONS, -e EXTENSIONS
1126
1127 Specifies which file extensions in the app template should be rendered
1128 with the template engine. Defaults to py.
1129
1130 --name FILES, -n FILES
1131
1132 Specifies which files in the app template (in addition to those match‐
1133 ing --extension) should be rendered with the template engine. Defaults
1134 to an empty list.
1135
1136 The template context used for all matching files is:
1137
1138 · Any option passed to the startapp command (among the command’s sup‐
1139 ported options)
1140
1141 · app_name – the app name as passed to the command
1142
1143 · app_directory – the full path of the newly created app
1144
1145 · camel_case_app_name – the app name in camel case format
1146
1147 · docs_version – the version of the documentation: 'dev' or '1.x'
1148
1149 WARNING:
1150 When the app template files are rendered with the Django template
1151 engine (by default all *.py files), Django will also replace all
1152 stray template variables contained. For example, if one of the
1153 Python files contains a docstring explaining a particular feature
1154 related to template rendering, it might result in an incorrect exam‐
1155 ple.
1156
1157 To work around this problem, you can use the templatetag templatetag
1158 to “escape” the various parts of the template syntax.
1159
1160 In addition, to allow Python template files that contain Django tem‐
1161 plate language syntax while also preventing packaging systems from
1162 trying to byte-compile invalid *.py files, template files ending
1163 with .py-tpl will be renamed to .py.
1164
1165 startproject
1166 django-admin startproject name [directory]
1167
1168 Creates a Django project directory structure for the given project name
1169 in the current directory or the given destination.
1170
1171 By default, the new directory contains manage.py and a project package
1172 (containing a settings.py and other files). See the template source for
1173 details.
1174
1175 If only the project name is given, both the project directory and
1176 project package will be named <projectname> and the project directory
1177 will be created in the current working directory.
1178
1179 If the optional destination is provided, Django will use that existing
1180 directory as the project directory, and create manage.py and the
1181 project package within it. Use ‘.’ to denote the current working direc‐
1182 tory.
1183
1184 For example:
1185
1186 django-admin startproject myproject /Users/jezdez/Code/myproject_repo
1187
1188 --template TEMPLATE
1189
1190 Specifies a directory, file path, or URL of a custom project template.
1191 See the startapp --template documentation for examples and usage.
1192
1193 --extension EXTENSIONS, -e EXTENSIONS
1194
1195 Specifies which file extensions in the project template should be ren‐
1196 dered with the template engine. Defaults to py.
1197
1198 --name FILES, -n FILES
1199
1200 Specifies which files in the project template (in addition to those
1201 matching --extension) should be rendered with the template engine.
1202 Defaults to an empty list.
1203
1204 The template context used is:
1205
1206 · Any option passed to the startproject command (among the command’s
1207 supported options)
1208
1209 · project_name – the project name as passed to the command
1210
1211 · project_directory – the full path of the newly created project
1212
1213 · secret_key – a random key for the SECRET_KEY setting
1214
1215 · docs_version – the version of the documentation: 'dev' or '1.x'
1216
1217 Please also see the rendering warning as mentioned for startapp.
1218
1219 test
1220 django-admin test [test_label [test_label ...]]
1221
1222 Runs tests for all installed apps. See /topics/testing/index for more
1223 information.
1224
1225 --failfast
1226
1227 Stops running tests and reports the failure immediately after a test
1228 fails.
1229
1230 --testrunner TESTRUNNER
1231
1232 Controls the test runner class that is used to execute tests. This
1233 value overrides the value provided by the TEST_RUNNER setting.
1234
1235 --noinput, --no-input
1236
1237 Suppresses all user prompts. A typical prompt is a warning about delet‐
1238 ing an existing test database.
1239
1240 Test runner options
1241 The test command receives options on behalf of the specified
1242 --testrunner. These are the options of the default test runner: Discov‐
1243 erRunner.
1244
1245 --keepdb, -k
1246
1247 Preserves the test database between test runs. This has the advantage
1248 of skipping both the create and destroy actions which can greatly
1249 decrease the time to run tests, especially those in a large test suite.
1250 If the test database does not exist, it will be created on the first
1251 run and then preserved for each subsequent run. Any unapplied migra‐
1252 tions will also be applied to the test database before running the test
1253 suite.
1254
1255 --reverse, -r
1256
1257 Sorts test cases in the opposite execution order. This may help in
1258 debugging the side effects of tests that aren’t properly isolated.
1259 Grouping by test class is preserved when using this option.
1260
1261 --debug-mode
1262
1263
1264
1265 Sets the DEBUG setting to True prior to running tests. This may help
1266 troubleshoot test failures.
1267
1268 --debug-sql, -d
1269
1270 Enables SQL logging for failing tests. If --verbosity is 2, then
1271 queries in passing tests are also output.
1272
1273 --parallel [N]
1274
1275 Runs tests in separate parallel processes. Since modern processors have
1276 multiple cores, this allows running tests significantly faster.
1277
1278 By default --parallel runs one process per core according to
1279 multiprocessing.cpu_count(). You can adjust the number of processes
1280 either by providing it as the option’s value, e.g. --parallel=4, or by
1281 setting the DJANGO_TEST_PROCESSES environment variable.
1282
1283 Django distributes test cases — unittest.TestCase subclasses — to sub‐
1284 processes. If there are fewer test cases than configured processes,
1285 Django will reduce the number of processes accordingly.
1286
1287 Each process gets its own database. You must ensure that different test
1288 cases don’t access the same resources. For instance, test cases that
1289 touch the filesystem should create a temporary directory for their own
1290 use.
1291
1292 This option requires the third-party tblib package to display trace‐
1293 backs correctly:
1294
1295 $ pip install tblib
1296
1297 This feature isn’t available on Windows. It doesn’t work with the Ora‐
1298 cle database backend either.
1299
1300 If you want to use pdb while debugging tests, you must disable parallel
1301 execution (--parallel=1). You’ll see something like bdb.BdbQuit if you
1302 don’t.
1303
1304 WARNING:
1305 When test parallelization is enabled and a test fails, Django may be
1306 unable to display the exception traceback. This can make debugging
1307 difficult. If you encounter this problem, run the affected test
1308 without parallelization to see the traceback of the failure.
1309
1310 This is a known limitation. It arises from the need to serialize
1311 objects in order to exchange them between processes. See What can be
1312 pickled and unpickled? for details.
1313
1314 --tag TAGS
1315
1316 Runs only tests marked with the specified tags. May be specified mul‐
1317 tiple times and combined with test --exclude-tag.
1318
1319 --exclude-tag EXCLUDE_TAGS
1320
1321 Excludes tests marked with the specified tags. May be specified multi‐
1322 ple times and combined with test --tag.
1323
1324 testserver
1325 django-admin testserver [fixture [fixture ...]]
1326
1327 Runs a Django development server (as in runserver) using data from the
1328 given fixture(s).
1329
1330 For example, this command:
1331
1332 django-admin testserver mydata.json
1333
1334 …would perform the following steps:
1335
1336 1. Create a test database, as described in the-test-database.
1337
1338 2. Populate the test database with fixture data from the given fix‐
1339 tures. (For more on fixtures, see the documentation for loaddata
1340 above.)
1341
1342 3. Runs the Django development server (as in runserver), pointed at
1343 this newly created test database instead of your production data‐
1344 base.
1345
1346 This is useful in a number of ways:
1347
1348 · When you’re writing unit tests of how your views act with certain
1349 fixture data, you can use testserver to interact with the views in a
1350 Web browser, manually.
1351
1352 · Let’s say you’re developing your Django application and have a “pris‐
1353 tine” copy of a database that you’d like to interact with. You can
1354 dump your database to a fixture (using the dumpdata command,
1355 explained above), then use testserver to run your Web application
1356 with that data. With this arrangement, you have the flexibility of
1357 messing up your data in any way, knowing that whatever data changes
1358 you’re making are only being made to a test database.
1359
1360 Note that this server does not automatically detect changes to your
1361 Python source code (as runserver does). It does, however, detect
1362 changes to templates.
1363
1364 --addrport ADDRPORT
1365
1366 Specifies a different port, or IP address and port, from the default of
1367 127.0.0.1:8000. This value follows exactly the same format and serves
1368 exactly the same function as the argument to the runserver command.
1369
1370 Examples:
1371
1372 To run the test server on port 7000 with fixture1 and fixture2:
1373
1374 django-admin testserver --addrport 7000 fixture1 fixture2
1375 django-admin testserver fixture1 fixture2 --addrport 7000
1376
1377 (The above statements are equivalent. We include both of them to demon‐
1378 strate that it doesn’t matter whether the options come before or after
1379 the fixture arguments.)
1380
1381 To run on 1.2.3.4:7000 with a test fixture:
1382
1383 django-admin testserver --addrport 1.2.3.4:7000 test
1384
1385 --noinput, --no-input
1386
1387 Suppresses all user prompts. A typical prompt is a warning about delet‐
1388 ing an existing test database.
1389
1391 Some commands are only available when the django.contrib application
1392 that implements them has been enabled. This section describes them
1393 grouped by their application.
1394
1395 django.contrib.auth
1396 changepassword
1397 django-admin changepassword [<username>]
1398
1399 This command is only available if Django’s authentication system
1400 (django.contrib.auth) is installed.
1401
1402 Allows changing a user’s password. It prompts you to enter a new pass‐
1403 word twice for the given user. If the entries are identical, this imme‐
1404 diately becomes the new password. If you do not supply a user, the com‐
1405 mand will attempt to change the password whose username matches the
1406 current user.
1407
1408 --database DATABASE
1409
1410 Specifies the database to query for the user. Defaults to default.
1411
1412 Example usage:
1413
1414 django-admin changepassword ringo
1415
1416 createsuperuser
1417 django-admin createsuperuser
1418
1419 This command is only available if Django’s authentication system
1420 (django.contrib.auth) is installed.
1421
1422 Creates a superuser account (a user who has all permissions). This is
1423 useful if you need to create an initial superuser account or if you
1424 need to programmatically generate superuser accounts for your site(s).
1425
1426 When run interactively, this command will prompt for a password for the
1427 new superuser account. When run non-interactively, no password will be
1428 set, and the superuser account will not be able to log in until a pass‐
1429 word has been manually set for it.
1430
1431 --username USERNAME
1432
1433 --email EMAIL
1434
1435 The username and email address for the new account can be supplied by
1436 using the --username and --email arguments on the command line. If
1437 either of those is not supplied, createsuperuser will prompt for it
1438 when running interactively.
1439
1440 --database DATABASE
1441
1442 Specifies the database into which the superuser object will be saved.
1443
1444 You can subclass the management command and override get_input_data()
1445 if you want to customize data input and validation. Consult the source
1446 code for details on the existing implementation and the method’s param‐
1447 eters. For example, it could be useful if you have a ForeignKey in
1448 REQUIRED_FIELDS and want to allow creating an instance instead of
1449 entering the primary key of an existing instance.
1450
1451 django.contrib.contenttypes
1452 remove_stale_contenttypes
1453 django-admin remove_stale_contenttypes
1454
1455
1456
1457 This command is only available if Django’s contenttypes app
1458 (django.contrib.contenttypes) is installed.
1459
1460 Deletes stale content types (from deleted models) in your database. Any
1461 objects that depend on the deleted content types will also be deleted.
1462 A list of deleted objects will be displayed before you confirm it’s
1463 okay to proceed with the deletion.
1464
1465 --database DATABASE
1466
1467 Specifies the database to use. Defaults to default.
1468
1469 django.contrib.gis
1470 ogrinspect
1471 This command is only available if GeoDjango (django.contrib.gis) is
1472 installed.
1473
1474 Please refer to its description in the GeoDjango documentation.
1475
1476 django.contrib.sessions
1477 clearsessions
1478 django-admin clearsessions
1479
1480 Can be run as a cron job or directly to clean out expired sessions.
1481
1482 django.contrib.sitemaps
1483 ping_google
1484 This command is only available if the Sitemaps framework (django.con‐
1485 trib.sitemaps) is installed.
1486
1487 Please refer to its description in the Sitemaps documentation.
1488
1489 django.contrib.staticfiles
1490 collectstatic
1491 This command is only available if the static files application
1492 (django.contrib.staticfiles) is installed.
1493
1494 Please refer to its description in the staticfiles documentation.
1495
1496 findstatic
1497 This command is only available if the static files application
1498 (django.contrib.staticfiles) is installed.
1499
1500 Please refer to its description in the staticfiles documentation.
1501
1503 Although some commands may allow their own custom options, every com‐
1504 mand allows for the following options:
1505
1506 --pythonpath PYTHONPATH
1507
1508 Adds the given filesystem path to the Python import search path. If
1509 this isn’t provided, django-admin will use the PYTHONPATH environment
1510 variable.
1511
1512 This option is unnecessary in manage.py, because it takes care of set‐
1513 ting the Python path for you.
1514
1515 Example usage:
1516
1517 django-admin migrate --pythonpath='/home/djangoprojects/myproject'
1518
1519 --settings SETTINGS
1520
1521 Specifies the settings module to use. The settings module should be in
1522 Python package syntax, e.g. mysite.settings. If this isn’t provided,
1523 django-admin will use the DJANGO_SETTINGS_MODULE environment variable.
1524
1525 This option is unnecessary in manage.py, because it uses settings.py
1526 from the current project by default.
1527
1528 Example usage:
1529
1530 django-admin migrate --settings=mysite.settings
1531
1532 --traceback
1533
1534 Displays a full stack trace when a CommandError is raised. By default,
1535 django-admin will show a simple error message when a CommandError
1536 occurs and a full stack trace for any other exception.
1537
1538 Example usage:
1539
1540 django-admin migrate --traceback
1541
1542 --verbosity {0,1,2,3}, -v {0,1,2,3}
1543
1544 Specifies the amount of notification and debug information that a com‐
1545 mand should print to the console.
1546
1547 · 0 means no output.
1548
1549 · 1 means normal output (default).
1550
1551 · 2 means verbose output.
1552
1553 · 3 means very verbose output.
1554
1555 Example usage:
1556
1557 django-admin migrate --verbosity 2
1558
1559 --no-color
1560
1561 Disables colorized command output. Some commands format their output
1562 to be colorized. For example, errors will be printed to the console in
1563 red and SQL statements will be syntax highlighted.
1564
1565 Example usage:
1566
1567 django-admin runserver --no-color
1568
1570 Syntax coloring
1571 The django-admin / manage.py commands will use pretty color-coded out‐
1572 put if your terminal supports ANSI-colored output. It won’t use the
1573 color codes if you’re piping the command’s output to another program.
1574
1575 Under Windows, the native console doesn’t support ANSI escape sequences
1576 so by default there is no color output. But you can install the ANSICON
1577 third-party tool, the Django commands will detect its presence and will
1578 make use of its services to color output just like on Unix-based plat‐
1579 forms.
1580
1581 The colors used for syntax highlighting can be customized. Django ships
1582 with three color palettes:
1583
1584 · dark, suited to terminals that show white text on a black background.
1585 This is the default palette.
1586
1587 · light, suited to terminals that show black text on a white back‐
1588 ground.
1589
1590 · nocolor, which disables syntax highlighting.
1591
1592 You select a palette by setting a DJANGO_COLORS environment variable to
1593 specify the palette you want to use. For example, to specify the light
1594 palette under a Unix or OS/X BASH shell, you would run the following at
1595 a command prompt:
1596
1597 export DJANGO_COLORS="light"
1598
1599 You can also customize the colors that are used. Django specifies a
1600 number of roles in which color is used:
1601
1602 · error - A major error.
1603
1604 · notice - A minor error.
1605
1606 · success - A success.
1607
1608 · warning - A warning.
1609
1610 · sql_field - The name of a model field in SQL.
1611
1612 · sql_coltype - The type of a model field in SQL.
1613
1614 · sql_keyword - An SQL keyword.
1615
1616 · sql_table - The name of a model in SQL.
1617
1618 · http_info - A 1XX HTTP Informational server response.
1619
1620 · http_success - A 2XX HTTP Success server response.
1621
1622 · http_not_modified - A 304 HTTP Not Modified server response.
1623
1624 · http_redirect - A 3XX HTTP Redirect server response other than 304.
1625
1626 · http_not_found - A 404 HTTP Not Found server response.
1627
1628 · http_bad_request - A 4XX HTTP Bad Request server response other than
1629 404.
1630
1631 · http_server_error - A 5XX HTTP Server Error response.
1632
1633 · migrate_heading - A heading in a migrations management command.
1634
1635 · migrate_label - A migration name.
1636
1637 Each of these roles can be assigned a specific foreground and back‐
1638 ground color, from the following list:
1639
1640 · black
1641
1642 · red
1643
1644 · green
1645
1646 · yellow
1647
1648 · blue
1649
1650 · magenta
1651
1652 · cyan
1653
1654 · white
1655
1656 Each of these colors can then be modified by using the following dis‐
1657 play options:
1658
1659 · bold
1660
1661 · underscore
1662
1663 · blink
1664
1665 · reverse
1666
1667 · conceal
1668
1669 A color specification follows one of the following patterns:
1670
1671 · role=fg
1672
1673 · role=fg/bg
1674
1675 · role=fg,option,option
1676
1677 · role=fg/bg,option,option
1678
1679 where role is the name of a valid color role, fg is the foreground
1680 color, bg is the background color and each option is one of the color
1681 modifying options. Multiple color specifications are then separated by
1682 a semicolon. For example:
1683
1684 export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
1685
1686 would specify that errors be displayed using blinking yellow on blue,
1687 and notices displayed using magenta. All other color roles would be
1688 left uncolored.
1689
1690 Colors can also be specified by extending a base palette. If you put a
1691 palette name in a color specification, all the colors implied by that
1692 palette will be loaded. So:
1693
1694 export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
1695
1696 would specify the use of all the colors in the light color palette,
1697 except for the colors for errors and notices which would be overridden
1698 as specified.
1699
1700 Bash completion
1701 If you use the Bash shell, consider installing the Django bash comple‐
1702 tion script, which lives in extras/django_bash_completion in the Django
1703 distribution. It enables tab-completion of django-admin and manage.py
1704 commands, so you can, for instance…
1705
1706 · Type django-admin.
1707
1708 · Press [TAB] to see all available options.
1709
1710 · Type sql, then [TAB], to see all available options whose names start
1711 with sql.
1712
1713 See /howto/custom-management-commands for how to add customized
1714 actions.
1715
1716 django.core.management.call_command(name, *args, **options)
1717
1718 To call a management command from code use call_command.
1719
1720 name the name of the command to call or a command object. Passing the
1721 name is preferred unless the object is required for testing.
1722
1723 *args a list of arguments accepted by the command. Arguments are
1724 passed to the argument parser, so you can use the same style as
1725 you would on the command line. For example, call_com‐
1726 mand('flush', '--verbosity=0').
1727
1728 **options
1729 named options accepted on the command-line. Options are passed
1730 to the command without triggering the argument parser, which
1731 means you’ll need to pass the correct type. For example,
1732 call_command('flush', verbosity=0) (zero must be an integer
1733 rather than a string).
1734
1735 Examples:
1736
1737 from django.core import management
1738 from django.core.management.commands import loaddata
1739
1740 management.call_command('flush', verbosity=0, interactive=False)
1741 management.call_command('loaddata', 'test_data', verbosity=0)
1742 management.call_command(loaddata.Command(), 'test_data', verbosity=0)
1743
1744 Note that command options that take no arguments are passed as keywords
1745 with True or False, as you can see with the interactive option above.
1746
1747 Named arguments can be passed by using either one of the following syn‐
1748 taxes:
1749
1750 # Similar to the command line
1751 management.call_command('dumpdata', '--natural-foreign')
1752
1753 # Named argument similar to the command line minus the initial dashes and
1754 # with internal dashes replaced by underscores
1755 management.call_command('dumpdata', natural_foreign=True)
1756
1757 # `use_natural_foreign_keys` is the option destination variable
1758 management.call_command('dumpdata', use_natural_foreign_keys=True)
1759
1760 Some command options have different names when using call_command()
1761 instead of django-admin or manage.py. For example, django-admin create‐
1762 superuser --no-input translates to call_command('createsuperuser',
1763 interactive=False). To find what keyword argument name to use for
1764 call_command(), check the command’s source code for the dest argument
1765 passed to parser.add_argument().
1766
1767 Command options which take multiple options are passed a list:
1768
1769 management.call_command('dumpdata', exclude=['contenttypes', 'auth'])
1770
1771 The return value of the call_command() function is the same as the
1772 return value of the handle() method of the command.
1773
1775 Note that you can redirect standard output and error streams as all
1776 commands support the stdout and stderr options. For example, you could
1777 write:
1778
1779 with open('/path/to/command_output') as f:
1780 management.call_command('dumpdata', stdout=f)
1781
1783 Django Software Foundation
1784
1786 Django Software Foundation and contributors
1787
1788
1789
1790
17912.0 September 22, 2017 DJANGO-ADMIN(1)