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