django-admin
和 manage.py
¶
django-admin
是 Django 的用于管理任务的命令行实用程序。本文档概述了它的所有功能。
此外,manage.py
会在每个 Django 项目中自动创建。它与 django-admin
的功能相同,但还会设置 DJANGO_SETTINGS_MODULE
环境变量,使其指向项目的 settings.py
文件。
如果你通过 pip
安装了 Django,django-admin
脚本应位于你的系统路径中。如果它不在你的路径中,请确保你已激活虚拟环境。
通常,在处理单个 Django 项目时,使用 manage.py
比使用 django-admin
更容易。如果您需要在多个 Django 设置文件之间切换,请将 django-admin
与 DJANGO_SETTINGS_MODULE
或 --settings
命令行选项配合使用。
本文档中的命令行示例使用 django-admin
以保持一致,但任何示例都可以同样使用 manage.py
或 python -m django
。
用法¶
$ django-admin <command> [options]
$ manage.py <command> [options]
$ python -m django <command> [options]
...\> django-admin <command> [options]
...\> manage.py <command> [options]
...\> py -m django <command> [options]
command
应为本文档中列出的命令之一。 options
是可选的,应为给定命令可用的选项中的零个或多个。
获取运行时帮助¶
-
django-admin help
¶
运行 django-admin help
以显示用法信息和每个应用程序提供的命令列表。
运行 django-admin help --commands
以显示所有可用命令的列表。
运行 django-admin help <command>
以显示给定命令的描述及其可用选项的列表。
应用名称¶
许多命令采用“应用名称”列表。“应用名称”是包含模型的包的基本名称。例如,如果您的 INSTALLED_APPS
包含字符串 'mysite.blog'
,则应用名称为 blog
。
确定版本¶
-
django-admin version
¶
运行 django-admin version
以显示当前 Django 版本。
输出遵循 PEP 440 中描述的架构
1.4.dev17026
1.4a1
1.4
显示调试输出¶
在支持的情况下,使用 --verbosity
来指定 django-admin
打印到控制台的通知和调试信息量。
可用命令¶
check
¶
-
django-admin check [app_label [app_label ...]]
¶
使用 系统检查框架 检查整个 Django 项目是否存在常见问题。
默认情况下,将检查所有应用。你可以通过提供应用标签列表作为参数来检查应用子集
django-admin check auth admin myapp
-
--tag
TAGS
,
-t
TAGS
¶
系统检查框架执行许多不同类型的检查,这些检查 按标签分类。你可以使用这些标签将执行的检查限制为特定类别中的检查。例如,要仅执行模型和兼容性检查,请运行
django-admin check --tag models --tag compatibility
-
--database
数据库
¶
指定运行需要数据库访问的检查的数据库
django-admin check --database default --database other
默认情况下,不会运行这些检查。
-
--list-tags
¶
列出所有可用的标签。
-
--deploy
¶
激活一些仅在部署设置中相关的附加检查。
可以在本地开发环境中使用此选项,但由于本地开发设置模块可能没有许多生产设置,因此可能希望将 check
命令指向不同的设置模块,方法是设置 DJANGO_SETTINGS_MODULE
环境变量,或通过传递 --settings
选项
django-admin check --deploy --settings=production_settings
或者可以在生产或暂存部署上直接运行它,以验证是否使用了正确的设置(省略 --settings
)。甚至可以将其作为集成测试套件的一部分。
-
--fail-level
{CRITICAL,ERROR,WARNING,INFO,DEBUG}
¶
指定将导致命令以非零状态退出的消息级别。默认值为 ERROR
。
compilemessages
¶
-
django-admin compilemessages
¶
将 makemessages
创建的 .po
文件编译为 .mo
文件,以与内置的 gettext 支持一起使用。请参阅 国际化和本地化。
-
--locale
语言环境
,
-l
语言环境
¶
指定要处理的区域设置。如果未提供,则处理所有区域设置。
-
--exclude
EXCLUDE
,
-x
EXCLUDE
¶
指定要从处理中排除的区域设置。如果未提供,则不排除任何区域设置。
-
--use-fuzzy
,
-f
¶
将模糊翻译包含到已编译文件中。
示例用法
django-admin compilemessages --locale=pt_BR
django-admin compilemessages --locale=pt_BR --locale=fr -f
django-admin compilemessages -l pt_BR
django-admin compilemessages -l pt_BR -l fr --use-fuzzy
django-admin compilemessages --exclude=pt_BR
django-admin compilemessages --exclude=pt_BR --exclude=fr
django-admin compilemessages -x pt_BR
django-admin compilemessages -x pt_BR -x fr
-
--ignore
PATTERN
,
-i
PATTERN
¶
忽略与给定glob
样式模式匹配的目录。多次使用以忽略更多内容。
示例用法
django-admin compilemessages --ignore=cache --ignore=outdated/*/locale
createcachetable
¶
-
django-admin createcachetable
¶
使用设置文件中的信息,为使用数据库缓存后端创建缓存表。有关详细信息,请参阅Django 的缓存框架。
-
--database
DATABASE
¶
指定将在其中创建缓存表的数据库。默认为default
。
-
--dry-run
¶
打印将运行的 SQL,而不会实际运行它,以便您可以自定义它或使用迁移框架。
dbshell
¶
-
django-admin dbshell
¶
使用 ENGINE
设置中指定的数据库引擎的命令行客户端,并使用 USER
、PASSWORD
等设置中指定的连接参数。
- 对于 PostgreSQL,这将运行
psql
命令行客户端。 - 对于 MySQL,这将运行
mysql
命令行客户端。 - 对于 SQLite,这将运行
sqlite3
命令行客户端。 - 对于 Oracle,这将运行
sqlplus
命令行客户端。
此命令假定程序位于您的 PATH
中,以便对程序名称(psql
、mysql
、sqlite3
、sqlplus
)的调用可以在正确的位置找到该程序。没有办法手动指定程序的位置。
-
--database
DATABASE
¶
指定要打开 shell 的数据库。默认为 default
。
-
--
ARGUMENTS
¶
在 --
分隔符后面的任何参数都将传递给底层命令行客户端。例如,对于 PostgreSQL,您可以使用 psql
命令的 -c
标志直接执行原始 SQL 查询
$ django-admin dbshell -- -c 'select current_user'
current_user
--------------
postgres
(1 row)
...\> django-admin dbshell -- -c 'select current_user'
current_user
--------------
postgres
(1 row)
在 MySQL/MariaDB 上,您可以使用 mysql
命令的 -e
标志执行此操作
$ django-admin dbshell -- -e "select user()"
+----------------------+
| user() |
+----------------------+
| djangonaut@localhost |
+----------------------+
...\> django-admin dbshell -- -e "select user()"
+----------------------+
| user() |
+----------------------+
| djangonaut@localhost |
+----------------------+
注意
请注意,并非 OPTIONS
部分中设置的所有选项都传递给命令行客户端,例如 'isolation_level'
。
diffsettings
¶
-
django-admin diffsettings
¶
显示当前设置文件与 Django 的默认设置(或由 --default
指定的另一个设置文件)之间的差异。
未出现在默认设置中的设置后面会跟有 "###"
。例如,默认设置未定义 ROOT_URLCONF
,因此 ROOT_URLCONF
后面会跟有 "###"
。
-
--all
¶
显示所有设置,即使它们具有 Django 的默认值。此类设置前面会加上 "###"
。
-
--default
MODULE
¶
将当前设置与之进行比较的设置模块。留空以与 Django 的默认设置进行比较。
-
--output
{hash,unified}
¶
指定输出格式。可用值是 hash
和 unified
。 hash
是显示上述输出的默认模式。 unified
显示类似于 diff -u
的输出。默认设置前缀为减号,后跟前缀为加号的已更改设置。
dumpdata
¶
-
django-admin dumpdata [app_label[.ModelName] [app_label[.ModelName] ...]]
¶
输出与指定应用程序关联的数据库中的所有数据到标准输出。
如果没有提供应用程序名称,将转储所有已安装的应用程序。
dumpdata
的输出可以用作 loaddata
的输入。
当 dumpdata
的结果保存为文件时,它可以作为 固定装置 用于 测试 或作为 初始数据。
请注意,dumpdata
使用模型上的默认管理器来选择要转储的记录。如果您将 自定义管理器 用作默认管理器,并且它过滤了一些可用记录,则并非所有对象都将被转储。
-
--all
,
-a
¶
使用 Django 的基本管理器,转储可能被自定义管理器过滤或修改的记录。
-
--format
FORMAT
¶
指定输出的序列化格式。默认为 JSON。支持的格式列在 序列化格式 中。
-
--indent
INDENT
¶
指定输出中要使用的缩进空格数。默认为 None
,它将所有数据显示在单行上。
-
--exclude
EXCLUDE
,
-e
EXCLUDE
¶
防止特定应用程序或模型(以 app_label.ModelName
的形式指定)被转储。如果您指定了一个模型名称,那么只有该模型将被排除,而不是整个应用程序。您还可以混合应用程序名称和模型名称。
如果您想排除多个应用程序,请多次传递 --exclude
django-admin dumpdata --exclude=auth --exclude=contenttypes
-
--database
DATABASE
¶
指定将从中转储数据的数据库。默认为 default
。
-
--natural-foreign
¶
使用 natural_key()
模型方法将任何外键和多对多关系序列化为定义该方法的类型的对象。如果您要转储 contrib.auth
Permission
对象或 contrib.contenttypes
ContentType
对象,您可能应该使用此标志。有关此选项和下一个选项的更多详细信息,请参阅 自然键 文档。
-
--natural-primary
¶
在该对象的序列化数据中省略主键,因为可以在反序列化期间计算主键。
-
--pks
PRIMARY_KEYS
¶
仅输出由主键逗号分隔列表指定的对象。仅在转储一个模型时可用。默认情况下,将输出模型的所有记录。
-
--output
OUTPUT
,
-o
OUTPUT
¶
指定要将序列化数据写入的文件。默认情况下,数据将转到标准输出。
当设置此选项且--verbosity
大于 0(默认值)时,将在终端中显示进度条。
Fixtures 压缩¶
输出文件可以使用bz2
、gz
、lzma
或xz
格式之一进行压缩,方法是使用相应扩展名结束文件名。例如,要将数据输出为压缩的 JSON 文件
django-admin dumpdata -o mydata.json.gz
flush
¶
-
django-admin flush
¶
从数据库中删除所有数据并重新执行任何后同步处理程序。不会清除已应用迁移的表。
如果您宁愿从一个空数据库开始并重新运行所有迁移,您应该删除并重新创建数据库,然后运行migrate
。
-
--noinput
,
--no-input
¶
禁止所有用户提示。
-
--database
DATABASE
¶
指定要刷新数据库。默认为default
。
inspectdb
¶
-
django-admin inspectdb [table [table ...]]
¶
内省由 NAME
设置指向的数据库中的数据库表,并输出 Django 模型模块(models.py
文件)到标准输出。
您可以通过将表或视图的名称作为参数传递来选择要内省的表或视图。如果没有提供参数,则仅当使用 --include-views
选项时,才会为视图创建模型。如果使用 --include-partitions
选项,则会在 PostgreSQL 上为分区表创建模型。
如果您有想要与 Django 一起使用的旧数据库,请使用此选项。该脚本将内省数据库并为其中的每个表创建一个模型。
正如您所料,创建的模型将为表中的每个字段具有一个属性。请注意,inspectdb
在其字段名称输出中有一些特殊情况
- 如果
inspectdb
无法将列的类型映射到模型字段类型,它将使用TextField
并在生成的模型中字段旁边插入 Python 注释'This field type is a guess.'
。识别的字段可能取决于INSTALLED_APPS
中列出的应用程序。例如,django.contrib.postgres
添加了对几种 PostgreSQL 特定字段类型的识别。 - 如果数据库列名是 Python 保留字(例如
'pass'
、'class'
或'for'
),inspectdb
会将'_field'
附加到属性名称。例如,如果某个表有一个列'for'
,生成的模型将有一个字段'for_field'
,db_column
属性设置为'for'
。inspectdb
会在该字段旁边插入 Python 注释'Field renamed because it was a Python reserved word.'
。
此功能旨在作为快捷方式,而不是明确的模型生成。运行此功能后,您需要自己查看生成的模型以进行自定义。特别是,您需要重新排列模型的顺序,以便引用其他模型的模型按正确顺序排列。
当在模型字段上指定 default
时,Django 不会创建数据库默认值。同样,数据库默认值不会被转换为模型字段默认值,也不会被 inspectdb
以任何方式检测到。
默认情况下,inspectdb
创建非托管模型。也就是说,模型的 Meta
类中的 managed = False
告诉 Django 不要管理每个表的创建、修改和删除。如果你确实希望允许 Django 管理表的生命周期,则需要将 managed
选项更改为 True
(或将其移除,因为 True
是其默认值)。
特定于数据库的注释¶
Oracle¶
- 如果使用了
--include-views
,则为物化视图创建模型。
PostgreSQL¶
- 为外键表创建模型。
- 如果使用了
--include-views
,则为物化视图创建模型。 - 如果使用了
--include-partitions
,则为分区表创建模型。
-
--database
DATABASE
¶
指定要内省的数据库。默认为 default
。
-
--include-partitions
¶
如果提供了此选项,则还为分区创建模型。
仅实现了对 PostgreSQL 的支持。
-
--include-views
¶
如果提供了此选项,则还为数据库视图创建模型。
loaddata
¶
-
django-admin loaddata fixture [fixture ...]
¶
搜索并加载命名的 fixture 的内容到数据库中。
-
--database
数据库
¶
指定将数据加载到的数据库。默认为 default
。
-
--ignorenonexistent
,
-i
¶
忽略自最初生成固定装置以来可能已被删除的字段和模型。
-
--app
应用标签
¶
指定一个应用来查找固定装置,而不是在所有应用中查找。
-
--format
格式
¶
指定 序列化格式(例如,json
或 xml
)用于 从标准输入读取的 固定装置。
-
--exclude
排除
,
-e
排除
¶
排除从给定应用程序和/或模型(采用 app_label
或 app_label.ModelName
的形式)加载固定装置。多次使用此选项以排除多个应用或模型。
从 stdin
加载固定装置¶
您可以使用破折号作为固定装置名称,以从 sys.stdin
加载输入。例如
django-admin loaddata --format=json -
从 stdin
读取时,--format
选项是必需的,以指定输入的 序列化格式(例如,json
或 xml
)。
从 stdin
加载对于标准输入和输出重定向非常有用。例如
django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -
dumpdata
命令可用于为 loaddata
生成输入。
另请参阅
有关固定装置的更多详细信息,请参阅 固定装置 主题。
makemessages
¶
-
django-admin makemessages
¶
在当前目录的整个源树上运行,并提取所有标记为翻译的字符串。它在 conf/locale(在 Django 树中)或 locale(对于项目和应用程序)目录中创建(或更新)消息文件。对消息文件进行更改后,您需要使用 compilemessages
编译它们,以便与内置的 gettext 支持一起使用。有关详细信息,请参阅 i18n 文档。
此命令不需要配置的设置。但是,当设置未配置时,该命令无法忽略 MEDIA_ROOT
和 STATIC_ROOT
目录或包含 LOCALE_PATHS
。
-
--all
,
-a
¶
更新所有可用语言的消息文件。
-
--extension
EXTENSIONS
,
-e
EXTENSIONS
¶
指定要检查的文件扩展名列表(默认值:html
、txt
、py
或 js
,如果 --domain
为 djangojs
)。
示例用法
django-admin makemessages --locale=de --extension xhtml
用逗号分隔多个扩展名或多次使用 -e
或 --extension
django-admin makemessages --locale=de --extension=html,txt --extension xml
-
--locale
LOCALE
,
-l
LOCALE
¶
指定要处理的语言环境。
-
--exclude
排除项
,
-x
排除项
¶
指定要从处理中排除的区域设置。如果未提供,则不排除任何区域设置。
示例用法
django-admin makemessages --locale=pt_BR
django-admin makemessages --locale=pt_BR --locale=fr
django-admin makemessages -l pt_BR
django-admin makemessages -l pt_BR -l fr
django-admin makemessages --exclude=pt_BR
django-admin makemessages --exclude=pt_BR --exclude=fr
django-admin makemessages -x pt_BR
django-admin makemessages -x pt_BR -x fr
-
--domain
域
,
-d
域
¶
指定消息文件的域。支持的选项有
django
适用于所有*.py
、*.html
和*.txt
文件(默认)djangojs
适用于*.js
文件
-
--symlinks
,
-s
¶
在查找新的翻译字符串时,沿着符号链接到目录。
示例用法
django-admin makemessages --locale=de --symlinks
-
--ignore
模式
,
-i
模式
¶
忽略与给定的 glob
样式模式匹配的文件或目录。多次使用以忽略更多内容。
默认情况下使用以下模式:'CVS'
、.*'
、'*~'
、*.pyc'
。
示例用法
django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html
-
--no-default-ignore
¶
禁用 --ignore
的默认值。
-
--no-wrap
¶
禁用在语言文件中将长消息行拆分为多行。
-
--no-location
¶
抑制在语言文件中写入“#: filename:line
”注释行。使用此选项会让技术娴熟的翻译人员更难理解每条消息的上下文。
-
--add-location
[{full,file,never}]
¶
控制语言文件中的 #: filename:line
注释行。如果选项是
full
(如果未给出,则为默认值):这些行同时包含文件名和行号。file
:省略行号。never
:抑制这些行(与--no-location
相同)。
需要 gettext
0.19 或更高版本。
-
--no-obsolete
¶
从 .po
文件中删除过时的消息字符串。
-
--keep-pot
¶
在创建 .po
文件之前,防止删除生成的临时 .pot
文件。这对于调试可能阻止创建最终语言文件的错误非常有用。
另请参阅
有关如何自定义 自定义 makemessages 命令 传递给 xgettext
的关键字的说明,请参阅 makemessages
。
makemigrations
¶
-
django-admin makemigrations [app_label [app_label ...]]
¶
根据检测到的模型更改创建新迁移。迁移及其与应用程序的关系等内容在 迁移文档 中进行了详细介绍。
提供一个或多个应用程序名称作为参数将把创建的迁移限制为指定的应用程序及其所需的任何依赖项(例如,ForeignKey
另一端的表)。
要将迁移添加到没有 migrations
目录的应用程序,请使用应用程序的 app_label
运行 makemigrations
。
-
--noinput
,
--no-input
¶
禁止所有用户提示。如果无法自动解决禁止的提示,该命令将退出,错误代码为 3。
-
--empty
¶
为指定的应用程序输出一个空迁移,以便手动编辑。这是为高级用户准备的,除非您熟悉迁移格式、迁移操作以及迁移之间的依赖关系,否则不应使用。
-
--dry-run
¶
显示将进行哪些迁移,而不实际将任何迁移文件写入磁盘。将此选项与 --verbosity 3
一起使用还将显示将编写的完整迁移文件。
-
--merge
¶
启用修复迁移冲突。
-
--name
名称
,
-n
名称
¶
允许对生成的迁移进行命名,而不是使用生成的名称。名称必须是有效的 Python 标识符。
-
--no-header
¶
生成不带 Django 版本和时间戳头的迁移文件。
-
--check
¶
当检测到没有迁移的模型更改时,使 makemigrations
以非零状态退出。暗示 --dry-run
。
在较早的版本中,使用 --check
选项时也会创建缺失的迁移。
-
--scriptable
¶
将日志输出和输入提示转到 stderr
,仅将生成的迁移文件的路径写入 stdout
。
-
--update
¶
将模型更改合并到最新的迁移中,并优化生成的操作。
更新的迁移将具有生成的名称。为了保留之前的名称,请使用 --name
进行设置。
migrate
¶
-
django-admin migrate [app_label] [migration_name]
¶
将数据库状态与当前模型和迁移集同步。迁移、它们与应用程序的关系等内容在迁移文档中进行了深入介绍。
此命令的行为会根据提供的参数而改变
- 无参数:所有应用程序都将运行其所有迁移。
<app_label>
:运行指定应用程序的迁移,直至最近的迁移。由于依赖关系,这可能涉及运行其他应用程序的迁移。<app_label> <migrationname>
:将数据库架构调整到已应用指定迁移的状态,但不会应用同一应用程序中的任何后续迁移。如果你之前已迁移到指定迁移之后,这可能涉及取消应用迁移。你可以使用迁移名称的前缀,例如0001
,只要它对给定的应用程序名称是唯一的即可。使用名称zero
以完全回退,即还原应用程序的所有已应用迁移。
警告
取消应用迁移时,所有依赖迁移也将被取消应用,无论<app_label>
如何。你可以使用 --plan
检查将取消应用哪些迁移。
-
--database
DATABASE
¶
指定要迁移的数据库。默认为 default
。
-
--fake
¶
将迁移标记为已应用(遵循上述规则),直至目标迁移,但实际上不会运行 SQL 来更改数据库架构。
此操作适用于高级用户,以便在手动应用更改时直接操作当前迁移状态;请注意,使用 --fake
有可能使迁移状态表进入需要手动恢复的状态,才能使迁移正确运行。
-
--fake-initial
¶
如果所有数据库表与所有 CreateModel
操作创建的所有模型的名称已经存在,则允许 Django 跳过应用程序的初始迁移。此选项适用于首次针对先于迁移使用的数据库运行迁移时。但是,此选项不会检查匹配的数据库架构,而只会匹配表名称,因此只有在您确信现有架构与初始迁移中记录的内容相匹配时才安全使用。
-
--plan
¶
显示针对给定的 migrate
命令执行的迁移操作。
-
--run-syncdb
¶
允许为没有迁移的应用程序创建表。虽然不建议这样做,但对于包含数百个模型的大型项目,迁移框架有时会太慢。
-
--noinput
,
--noinput
¶
禁止所有用户提示。一个示例提示是询问是否删除过时的内容类型。
-
--check
¶
当检测到未应用的迁移时,使 migrate
退出,且状态为非零。
-
--prune
¶
从 django_migrations
表中删除不存在的迁移。当被压缩迁移替换的迁移文件已被删除时,这非常有用。有关更多详细信息,请参阅 压缩迁移。
optimizemigration
¶
-
django-admin optimizemigration app_label migration_name
¶
优化指定迁移的操作并覆盖现有文件。如果迁移包含必须手动复制的函数,该命令将创建一个新的迁移文件,后缀为 _optimized
,用于替换指定的迁移。
-
--check
¶
当迁移可以优化时,使 optimizemigration
以非零状态退出。
runserver
¶
-
django-admin runserver [addrport]
¶
在本地计算机上启动轻量级开发 Web 服务器。默认情况下,服务器在 IP 地址 127.0.0.1
上的端口 8000 上运行。你可以明确地传入一个 IP 地址和端口号。
如果你以具有普通权限的用户身份运行此脚本(推荐),你可能无法访问启动低端口号上的端口。低端口号是为超级用户(root)保留的。
此服务器使用 WSGI_APPLICATION
设置指定的 WSGI 应用程序对象。
不要在生产环境中使用此服务器。它尚未经过安全审计或性能测试。(而且它将继续保持这种状态。我们的业务是制作 Web 框架,而不是 Web 服务器,因此改进此服务器以能够处理生产环境超出了 Django 的范围。)
开发服务器会根据需要自动为每个请求重新加载 Python 代码。你不必重新启动服务器才能使代码更改生效。但是,某些操作(如添加文件)不会触发重新启动,因此在这些情况下你必须重新启动服务器。
如果你正在使用 Linux 或 MacOS 并同时安装 pywatchman 和 Watchman 服务,则内核信号将用于自动重新加载服务器(而不是每秒轮询文件修改时间戳)。这在大项目上提供了更好的性能、代码更改后的响应时间缩短、更可靠的更改检测和降低的功耗。Django 支持 pywatchman
1.2.0 及更高版本。
包含许多文件的大型目录可能会导致性能问题
在将 Watchman 与包含大型非 Python 目录(如 node_modules
)的项目配合使用时,建议忽略此目录以获得最佳性能。请参阅 Watchman 文档 了解如何执行此操作的信息。
Watchman 超时
-
DJANGO_WATCHMAN_TIMEOUT
¶
Watchman
客户端的默认超时为 5 秒。你可以通过设置 DJANGO_WATCHMAN_TIMEOUT
环境变量来更改它。
当你启动服务器时,以及每次在服务器运行时更改 Python 代码时,系统检查框架会检查整个 Django 项目是否存在一些常见错误(请参阅 check
命令)。如果发现任何错误,它们将打印到标准输出。你可以使用 --skip-checks
选项来跳过运行系统检查。
你可以运行任意数量的并发服务器,只要它们位于不同的端口上,只需多次执行 django-admin runserver
即可。
请注意,默认 IP 地址 127.0.0.1
无法从网络上的其他计算机访问。若要使其他网络计算机可以查看你的开发服务器,请使用其自己的 IP 地址(例如 192.168.2.1
)、0
(0.0.0.0
的快捷方式)、0.0.0.0
或 ::
(启用 IPv6)。
你可以提供用方括号括起来的 IPv6 地址(例如 [200a::1]:8000
)。这将自动启用 IPv6 支持。
还可以使用包含仅 ASCII 字符的主机名。
如果启用了 staticfiles 辅助应用程序(新项目中的默认设置),则 runserver
命令将被其自己的 runserver 命令覆盖。
服务器的每个请求和响应的日志将发送到 django.server 记录器。
-
--noreload
¶
禁用自动重新加载器。这意味着当服务器正在运行时,您对 Python 代码所做的任何更改都不会生效,如果特定 Python 模块已加载到内存中。
-
--nothreading
¶
禁用在开发服务器中使用线程。默认情况下,服务器是多线程的。
-
--ipv6
,
-6
¶
对开发服务器使用 IPv6。这会将默认 IP 地址从 127.0.0.1
更改为 ::1
。
使用不同端口和地址的示例¶
IP 地址 127.0.0.1
上的端口 8000
django-admin runserver
IP 地址 1.2.3.4
上的端口 8000
django-admin runserver 1.2.3.4:8000
IP 地址 127.0.0.1
上的端口 7000
django-admin runserver 7000
IP 地址 1.2.3.4
上的端口 7000
django-admin runserver 1.2.3.4:7000
IPv6 地址 ::1
上的端口 8000
django-admin runserver -6
IPv6 地址 ::1
上的端口 7000
django-admin runserver -6 7000
IPv6 地址 2001:0db8:1234:5678::9
上的端口 7000
django-admin runserver [2001:0db8:1234:5678::9]:7000
主机 localhost
的 IPv4 地址上的端口 8000
django-admin runserver localhost:8000
主机 localhost
的 IPv6 地址上的端口 8000
django-admin runserver -6 localhost:8000
使用开发服务器提供静态文件¶
默认情况下,开发服务器不会为你的站点提供任何静态文件(例如 CSS 文件、图像、MEDIA_URL
下的内容等)。如果你想配置 Django 来提供静态媒体,请阅读 如何管理静态文件(例如图像、JavaScript、CSS)。
在开发中使用 ASGI 提供服务¶
Django 的 runserver
命令提供了一个 WSGI 服务器。为了在 ASGI 下运行,你需要使用一个 ASGI 服务器。Django Daphne 项目提供了 与 runserver 集成,你可以使用它。
sendtestemail
¶
-
django-admin sendtestemail [email [email ...]]
¶
向指定的收件人发送一封测试电子邮件(以确认通过 Django 发送电子邮件是否正常工作)。例如
django-admin sendtestemail [email protected] [email protected]
有几个选项,你可以将它们中的任意组合一起使用
-
--managers
¶
使用 mail_managers()
,将电子邮件发送到 MANAGERS
中指定的电子邮件地址。
-
--admins
¶
使用 mail_admins()
,将电子邮件发送到 ADMINS
中指定的电子邮件地址。
shell
¶
-
django-admin shell
¶
启动 Python 交互式解释器。
-
--interface
{ipython,bpython,python}
,
-i
{ipython,bpython,python}
¶
指定要使用的 shell。默认情况下,如果已安装,Django 将使用 IPython 或 bpython。如果两者都已安装,请指定您想要的一个,如下所示
IPython
django-admin shell -i ipython
bpython
django-admin shell -i bpython
如果您已安装“rich”shell,但希望强制使用“plain”Python 解释器,请使用 python
作为接口名称,如下所示
django-admin shell -i python
-
--nostartup
¶
禁用读取“plain”Python 解释器的启动脚本。默认情况下,将读取 PYTHONSTARTUP
环境变量或 ~/.pythonrc.py
脚本所指向的脚本。
-
--command
COMMAND
,
-c
COMMAND
¶
允许您将命令作为字符串传递,以将其作为 Django 执行,如下所示
django-admin shell --command="import django; print(django.__version__)"
您还可以传递标准输入中的代码来执行它。例如
$ django-admin shell <<EOF
> import django
> print(django.__version__)
> EOF
在 Windows 上,由于 select.select()
在该平台上的实现限制,因此会输出 REPL。
showmigrations
¶
-
django-admin showmigrations [app_label [app_label ...]]
¶
显示项目中的所有迁移。您可以选择以下两种格式之一
-
--list
,
-l
¶
列出 Django 了解的所有应用、每个应用可用的迁移以及每个迁移是否已应用(在迁移名称旁边标记为 [X]
)。对于 --verbosity
2 及以上,还会显示应用日期时间。
没有迁移的应用也会列出,但会在其下方打印 (no migrations)
。
这是默认输出格式。
-
--plan
,
-p
¶
显示 Django 将遵循的迁移计划以应用迁移。与 --list
类似,已应用的迁移用 [X]
标记。对于 --verbosity
2 及以上,还将显示迁移的所有依赖项。
app_label
参数限制输出,但提供的应用的依赖项也可能包括在内。
-
--database
DATABASE
¶
指定要检查的数据库。默认为 default
。
sqlflush
¶
-
django-admin sqlflush
¶
打印将为 flush
命令执行的 SQL 语句。
-
--database
DATABASE
¶
指定要打印 SQL 的数据库。默认为 default
。
sqlmigrate
¶
-
django-admin sqlmigrate app_label migration_name
¶
打印指定迁移的 SQL。这需要一个活动数据库连接,它将用于解析约束名称;这意味着你必须针对希望稍后应用数据库的副本生成 SQL。
请注意,sqlmigrate
不会对其输出进行着色。
-
--backwards
¶
生成用于取消应用迁移的 SQL。默认情况下,创建的 SQL 用于以正向运行迁移。
-
--database
DATABASE
¶
指定要为其生成 SQL 的数据库。默认为 default
。
sqlsequencereset
¶
-
django-admin sqlsequencereset app_label [app_label ...]
¶
打印用于重置指定应用程序名称的序列的 SQL 语句。
序列是某些数据库引擎用于跟踪自动递增字段的下一个可用数字的索引。
使用此命令生成 SQL,该 SQL 将修复序列与其自动递增字段数据不同步的情况。
-
--database
DATABASE
¶
指定要打印 SQL 的数据库。默认为 default
。
squashmigrations
¶
-
django-admin squashmigrations app_label [start_migration_name] migration_name
¶
压缩 app_label
的迁移,包括 migration_name
在内的迁移,尽可能减少迁移数量。生成的压缩迁移可以与未压缩的迁移安全地共存。有关更多信息,请阅读 压缩迁移。
当给出 start_migration_name
时,Django 将仅包含从该迁移开始(包括该迁移)的迁移。这有助于减轻 RunPython
和 django.db.migrations.operations.RunSQL
迁移操作的压缩限制。
-
--no-optimize
¶
在生成压缩迁移时禁用优化器。默认情况下,Django 将尝试优化迁移中的操作以减小生成文件的大小。如果此过程失败或创建了不正确的迁移,请使用此选项,但请同时提交一份 Django 缺陷报告,因为优化应该是安全的。
-
--noinput
,
--no-input
¶
禁止所有用户提示。
-
--squashed-name
SQUASHED_NAME
¶
设置压缩迁移的名称。如果省略,则该名称基于第一个和最后一个迁移,中间带有 _squashed_
。
-
--no-header
¶
生成不带 Django 版本和时间戳头的压缩迁移文件。
startapp
¶
-
django-admin startapp name [directory]
¶
在当前目录或给定目标中为给定的应用名称创建 Django 应用目录结构。
默认情况下,新目录包含 models.py
文件和其他应用模板文件。如果只给出了应用名称,则应用目录将在当前工作目录中创建。
如果提供了可选目标,Django 将使用该现有目录,而不是创建一个新目录。你可以使用“.”来表示当前工作目录。
例如
django-admin startapp myapp /Users/jezdez/Code/myapp
-
--template
TEMPLATE
¶
提供一个包含自定义应用模板文件的目录的路径,或一个未压缩的存档 (.tar
) 或一个压缩存档 (.tar.gz
, .tar.bz2
, .tar.xz
, .tar.lzma
, .tgz
, .tbz2
, .txz
, .tlz
, .zip
) 的路径,该存档包含应用模板文件。
例如,在创建 myapp
应用时,这将在给定的目录中查找应用模板
django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp
Django 还将接受包含应用模板文件的压缩存档的 URL (http
, https
, ftp
),并动态下载和解压它们。
例如,利用 GitHub 将存储库公开为 zip 文件的功能,你可以使用类似这样的 URL
django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/main.zip myapp
-
--extension
扩展名
,
-e
扩展名
¶
指定应用模板中应使用模板引擎呈现哪些文件扩展名。默认为 py
。
-
--name
文件
,
-n
文件
¶
指定应用模板中哪些文件(除了与 --extension
匹配的文件)应使用模板引擎呈现。默认为空列表。
-
--exclude
目录
,
-x
目录
¶
指定应用模板中哪些目录应排除,除了 .git
和 __pycache__
。如果未提供此选项,则会排除名为 __pycache__
或以 .
开头的目录。
用于所有匹配文件的是 template context
- 传递给
startapp
命令的任何选项(在命令支持的选项中) app_name
– 传递给命令的应用名称app_directory
– 新创建的应用的完整路径camel_case_app_name
– 驼峰格式的应用名称docs_version
– 文档版本:'dev'
或'1.x'
django_version
– Django 版本,例如'2.0.3'
警告
当应用程序模板文件使用 Django 模板引擎渲染时(默认情况下所有 *.py
文件),Django 还会替换其中包含的所有杂散模板变量。例如,如果某个 Python 文件包含解释与模板渲染相关的特定功能的文档字符串,则可能会导致示例不正确。
要解决此问题,可以使用 templatetag
模板标签来“转义”模板语法的各个部分。
此外,为了允许包含 Django 模板语言语法的 Python 模板文件,同时防止打包系统尝试对无效的 *.py
文件进行字节编译,以 .py-tpl
结尾的模板文件将重命名为 .py
。
警告
在使用之前,应始终审核自定义应用程序(或项目)模板的内容:此类模板定义将成为项目一部分的代码,这意味着此类代码将与安装的任何应用程序或自己编写的代码一样受到信任。此外,即使渲染模板,实际上也是在执行作为管理命令输入提供的代码。Django 模板语言可能会提供对系统的广泛访问,因此请确保使用的任何自定义模板都值得信赖。
startproject
¶
-
django-admin startproject name [directory]
¶
在当前目录或给定目标目录中为给定的项目名称创建 Django 项目目录结构。
默认情况下,新目录 包含 manage.py
和一个项目包(包含 settings.py
和其他文件)。
如果只给出了项目名称,则项目目录和项目包都将命名为 <projectname>
,并且项目目录将在当前工作目录中创建。
如果提供了可选目标,Django 将使用该现有目录作为项目目录,并在其中创建 manage.py
和项目包。使用 “.” 表示当前工作目录。
例如
django-admin startproject myproject /Users/jezdez/Code/myproject_repo
-
--template
模板
¶
指定自定义项目模板的目录、文件路径或 URL。有关示例和用法,请参见 startapp --template
文档。
-
--extension
扩展
,
-e
扩展
¶
指定项目模板中哪些文件扩展名应使用模板引擎呈现。默认为 py
。
-
--name
文件
,
-n
文件
¶
指定项目模板中哪些文件(除与 --extension
匹配的文件外)应使用模板引擎呈现。默认为空列表。
-
--exclude
目录
,
-x
目录
¶
指定项目模板中哪些目录应排除,除了 .git
和 __pycache__
。如果未提供此选项,则将排除名为 __pycache__
或以 .
开头的目录。
使用的 template context
是
- 传给
startproject
命令的任何选项(在命令支持的选项中) project_name
– 传给命令的项目名称project_directory
– 新创建项目的完整路径secret_key
–SECRET_KEY
设置的随机密钥docs_version
– 文档版本:'dev'
或'1.x'
django_version
– Django 版本,例如'2.0.3'
test
¶
-
django-admin test [test_label [test_label ...]]
¶
运行所有已安装应用程序的测试。有关更多信息,请参阅 Django 中的测试。
-
--failfast
¶
在测试失败后立即停止运行测试并报告失败。
-
--testrunner
TESTRUNNER
¶
控制用于执行测试的测试运行器类。此值将覆盖 TEST_RUNNER
设置提供的值。
-
--noinput
,
--no-input
¶
禁止所有用户提示。典型的提示是有关删除现有测试数据库的警告。
测试运行器选项¶
test
命令接收指定 --testrunner
的选项。以下是默认测试运行器的选项:DiscoverRunner
。
-
--keepdb
¶
在测试运行之间保留测试数据库。这具有跳过创建和销毁操作的优势,这可以极大地减少运行测试的时间,尤其是大型测试套件中的测试。如果测试数据库不存在,它将在第一次运行时创建,然后为每次后续运行保留。除非 MIGRATE
测试设置是 False
,任何未应用的迁移也会在运行测试套件之前应用于测试数据库。
-
--shuffle
[SEED]
¶
在运行测试之前随机化测试顺序。这有助于检测未正确隔离的测试。此选项生成的测试顺序是给定整数种子确定性函数。当没有传递种子时,将随机选择一个种子并打印到控制台。要重复特定的测试顺序,请传递一个种子。此选项生成的测试顺序保留了 Django 的 测试顺序保证。它们还按测试用例类对测试进行分组。
随机排序还具有在缩小隔离问题时有用的特殊一致性属性。即,对于给定的种子并且在运行测试子集时,新顺序将是原始随机限制在较小集合中。类似地,在保持种子相同的情况下添加测试时,原始测试的顺序在新顺序中将保持相同。
-
--reverse
,
-r
¶
以相反的执行顺序对测试用例进行排序。这有助于调试未正确隔离的测试的副作用。按测试类分组在使用此选项时保留。这可以与 --shuffle
结合使用,以反转特定种子的顺序。
-
--debug-mode
¶
在运行测试之前将 DEBUG
设置为 True
。这有助于解决测试失败问题。
-
--debug-sql
,
-d
¶
为失败的测试启用 SQL 日志记录。如果 --verbosity
为 2
,则也会输出通过测试中的查询。
-
--parallel
[N]
¶
-
DJANGO_TEST_PROCESSES
¶
在单独的并行进程中运行测试。由于现代处理器具有多个内核,这可以显著加快测试运行速度。
使用 --parallel
而没有值,或使用值 auto
,根据 multiprocessing.cpu_count()
,每个内核运行一个测试进程。您可以通过传递所需的进程数来覆盖此设置,例如 --parallel 4
,或通过设置 DJANGO_TEST_PROCESSES
环境变量。
Django 将测试用例(unittest.TestCase
子类)分发到子进程。如果测试用例类少于配置的进程,Django 将相应减少进程数。
每个进程都有自己的数据库。您必须确保不同的测试用例类不会访问相同的资源。例如,涉及文件系统的测试用例类应创建自己的临时目录供其使用。
注意
如果您有无法并行运行的测试类,可以使用 SerializeMixin
顺序运行它们。请参阅 强制顺序运行测试类。
此选项需要第三方 tblib
包才能正确显示回溯。
$ python -m pip install tblib
此功能在 Windows 上不可用。它也不适用于 Oracle 数据库后端。
如果您想在调试测试时使用 pdb
,您必须禁用并行执行(--parallel=1
)。如果不这样做,您将看到类似 bdb.BdbQuit
的内容。
警告
当测试并行化启用且测试失败时,Django 可能无法显示异常回溯。这会让调试变得困难。如果您遇到此问题,请在不启用并行化的前提下运行受影响的测试,以查看失败的回溯。
这是一个已知限制。它源于为了在进程之间交换对象而序列化对象的需求。有关详细信息,请参阅 可以腌制和反腌制什么?。
-
--tag
标签
¶
仅运行 标记了指定标签的测试。可以多次指定,并与 test --exclude-tag
结合使用。
始终认为加载失败的测试是匹配的。
-
--exclude-tag
排除标签
¶
排除 标记了指定标签的测试。可以多次指定,并与 test --tag
结合使用。
-
-k
测试名称模式
¶
运行与测试名称模式匹配的测试方法和类,方式与 unittest 的 -k 选项
相同。可以多次指定。
-
--pdb
¶
在每次测试错误或失败时生成一个 pdb
调试器。如果您已安装它,则会使用 ipdb
。
-
--buffer
,
-b
¶
放弃输出(stdout
和 stderr
)以通过测试,与 unittest 的 --buffer 选项
相同。
-
--no-faulthandler
¶
Django 在启动测试时自动调用 faulthandler.enable()
,如果解释器崩溃,它允许打印回溯。传递 --no-faulthandler
以禁用此行为。
-
--timing
¶
输出计时,包括数据库设置和总运行时间。
-
--durations
N
¶
显示 N 个最慢的测试用例(N=0 表示全部)。
Python 3.12 及更高版本
此功能仅适用于 Python 3.12 及更高版本。
testserver
¶
-
django-admin testserver [fixture [fixture ...]]
¶
使用给定固定装置的数据运行 Django 开发服务器(如 runserver
中)。
例如,此命令
django-admin testserver mydata.json
…将执行以下步骤
- 创建一个测试数据库,如 测试数据库 中所述。
- 使用给定的固定装置填充测试数据库中的固定装置数据。(有关固定装置的更多信息,请参阅
loaddata
的文档。) - 运行 Django 开发服务器(如
runserver
),指向新创建的测试数据库,而不是生产数据库。
这在许多方面很有用
- 当您编写 单元测试,了解您的视图如何使用某些固定装置数据时,您可以使用
testserver
手动在 Web 浏览器中与视图进行交互。 - 假设您正在开发 Django 应用程序,并且有一个“原始”数据库副本,您希望与其进行交互。您可以使用
dumpdata
命令将数据库转储到 固定装置(如上所述),然后使用testserver
运行您的 Web 应用程序,其中包含该数据。通过这种安排,您可以灵活地以任何方式弄乱您的数据,因为您所做的任何数据更改都只会对测试数据库进行。
请注意,此服务器不会自动检测到 Python 源代码的更改(如 runserver
所做的那样)。但是,它确实会检测到模板的更改。
-
--addrport
ADDRPORT
¶
指定与默认值 127.0.0.1:8000
不同的端口或 IP 地址和端口。此值遵循与 runserver
命令的参数完全相同的格式,并具有完全相同的功能。
示例
在端口 7000 上使用 fixture1
和 fixture2
运行测试服务器
django-admin testserver --addrport 7000 fixture1 fixture2
django-admin testserver fixture1 fixture2 --addrport 7000
(以上语句是等效的。我们同时包含它们是为了表明选项在 fixture 参数之前还是之后出现并不重要。)
在 1.2.3.4:7000 上使用 test
fixture 运行
django-admin testserver --addrport 1.2.3.4:7000 test
-
--noinput
,
--no-input
¶
禁止所有用户提示。典型的提示是有关删除现有测试数据库的警告。
应用程序提供的命令¶
某些命令仅在实现它们的 django.contrib
应用程序已 实现 并已 启用
时才可用。本部分按应用程序对它们进行分组描述。
django.contrib.auth
¶
changepassword
¶
-
django-admin changepassword [<username>]
¶
仅当已安装 Django 的 身份验证系统 (django.contrib.auth
) 时,此命令才可用。
允许更改用户的密码。它会提示您为给定用户两次输入新密码。如果输入的内容相同,则立即成为新密码。如果您未提供用户,则该命令将尝试更改用户名与当前用户匹配的密码。
-
--database
DATABASE
¶
指定要为用户查询的数据库。默认为 default
。
示例用法
django-admin changepassword ringo
创建超级用户
¶
-
django-admin 创建超级用户
¶
-
DJANGO_SUPERUSER_PASSWORD
¶
仅当已安装 Django 的 身份验证系统 (django.contrib.auth
) 时,此命令才可用。
创建超级用户帐户(拥有所有权限的用户)。如果您需要创建初始超级用户帐户或需要为您的网站以编程方式生成超级用户帐户,这将非常有用。
当交互式运行此命令时,它将提示输入新超级用户帐户的密码。当以非交互式方式运行时,您可以通过设置 DJANGO_SUPERUSER_PASSWORD
环境变量来提供密码。否则,将不会设置密码,并且超级用户帐户将无法登录,直到手动为其设置密码。
在非交互模式下,USERNAME_FIELD
和必需字段(列在 REQUIRED_FIELDS
)回退到 DJANGO_SUPERUSER_<uppercase_field_name>
环境变量,除非它们被命令行参数覆盖。例如,要提供 email
字段,可以使用 DJANGO_SUPERUSER_EMAIL
环境变量。
-
--noinput
,
--no-input
¶
禁止所有用户提示。如果无法自动解决禁止的提示,该命令将退出,错误代码为 1。
-
--username
USERNAME
¶
-
--email
EMAIL
¶
新帐户的用户名和电子邮件地址可以使用命令行上的 --username
和 --email
参数提供。如果未提供其中任何一个,createsuperuser
将在交互运行时提示输入。
-
--database
DATABASE
¶
指定将超级用户对象保存到的数据库。
如果您希望自定义数据输入和验证,可以对管理命令进行子类化并覆盖 get_input_data()
。有关现有实现和方法参数的详细信息,请查阅源代码。例如,如果您在 REQUIRED_FIELDS
中有 ForeignKey
并且希望允许创建实例而不是输入现有实例的主键,这将非常有用。
django.contrib.contenttypes
¶
remove_stale_contenttypes
¶
-
django-admin remove_stale_contenttypes
¶
只有在安装了 Django 的 contenttypes 应用程序 (django.contrib.contenttypes
) 时,此命令才可用。
删除数据库中陈旧的内容类型(来自已删除的模型)。任何依赖于已删除内容类型的对象也将被删除。在您确认可以继续删除之前,将显示已删除对象的列表。
-
--database
DATABASE
¶
指定要使用的数据库。默认为 default
。
-
--include-stale-apps
¶
删除陈旧的内容类型,包括已从 INSTALLED_APPS
中移除的先前已安装应用中的内容类型。默认为 False
。
django.contrib.gis
¶
django.contrib.staticfiles
¶
默认选项¶
尽管某些命令允许使用它们自己的自定义选项,但每个命令默认情况下都允许使用以下选项
-
--pythonpath
PYTHONPATH
¶
将给定的文件系统路径添加到 Python sys.path
模块属性。如果未提供此项,django-admin
将使用 PYTHONPATH
环境变量。
此选项在 manage.py
中是不必要的,因为它会负责为你设置 Python 路径。
示例用法
django-admin migrate --pythonpath='/home/djangoprojects/myproject'
-
--settings
SETTINGS
¶
指定要使用的设置模块。设置模块应采用 Python 包语法,例如 mysite.settings
。如果未提供此项,django-admin
将使用 DJANGO_SETTINGS_MODULE
环境变量。
此选项在 manage.py
中是不必要的,因为它默认使用当前项目中的 settings.py
。
示例用法
django-admin migrate --settings=mysite.settings
-
--traceback
¶
当引发 CommandError
时,显示完整的堆栈跟踪。默认情况下,当 CommandError
发生时,django-admin
将显示一条错误消息,而对于任何其他异常,它将显示完整的堆栈跟踪。
此选项被 runserver
忽略。
示例用法
django-admin migrate --traceback
-
--verbosity
{0,1,2,3}
,
-v
{0,1,2,3}
¶
指定命令应向控制台打印的通知和调试信息量。
0
表示无输出。1
表示正常输出(默认)。2
表示详细输出。3
表示非常详细的输出。
此选项被 runserver
忽略。
示例用法
django-admin migrate --verbosity 2
-
--no-color
¶
禁用彩色命令输出。某些命令会将输出格式化为彩色。例如,错误将以红色打印到控制台,SQL 语句将以语法高亮显示。
示例用法
django-admin runserver --no-color
-
--force-color
¶
强制对命令输出着色,如果按照 语法着色 中的讨论,它原本会被禁用。例如,您可能希望将彩色输出管道到另一个命令。
-
--skip-checks
¶
在运行命令之前跳过运行系统检查。仅当 requires_system_checks
命令属性不是空列表或元组时,此选项才可用。
示例用法
django-admin migrate --skip-checks
额外细节¶
语法着色¶
-
DJANGO_COLORS
¶
如果您的终端支持 ANSI 彩色输出,django-admin
/ manage.py
命令将使用漂亮的彩色编码输出。如果您将命令的输出管道传输到另一个程序,则它不会使用颜色代码,除非使用了 --force-color
选项。
Windows 支持¶
在 Windows 10 上,Windows 终端 应用程序、VS Code 和 PowerShell(已启用虚拟终端处理)允许彩色输出,并且默认情况下受支持。
在 Windows 下,旧版 cmd.exe
本机控制台不支持 ANSI 转义序列,因此默认情况下没有颜色输出。在这种情况下,需要以下两个第三方库之一
安装 colorama,这是一个 Python 包,可将 ANSI 颜色代码转换为 Windows API 调用。Django 命令将检测到它的存在,并将利用其服务对输出进行着色,就像在基于 Unix 的平台上一样。可以通过 pip 安装
colorama
...\> py -m pip install "colorama >= 0.4.6"
安装 ANSICON,这是一个第三方工具,允许
cmd.exe
处理 ANSI 颜色代码。Django 命令将检测到它的存在,并将利用其服务对输出进行着色,就像在基于 Unix 的平台上一样。
Windows 上的其他现代终端环境支持终端颜色,但 Django 不会自动检测到它们受支持,它们可以通过设置适当的环境变量 ANSICON="on"
来“伪造”ANSICON
的安装。
自定义颜色¶
用于语法高亮的色彩可以自定义。Django 配备了三个调色板
dark
,适用于在黑色背景上显示白色文本的终端。这是默认调色板。light
,适用于在白色背景上显示黑色文本的终端。nocolor
,禁用语法高亮。
通过设置 DJANGO_COLORS
环境变量来选择调色板,以指定要使用的调色板。例如,要在 Unix 或 OS/X BASH shell 下指定 light
调色板,可以在命令提示符下运行以下命令
export DJANGO_COLORS="light"
还可以自定义所使用的色彩。Django 指定了使用色彩的多个角色
error
- 重大错误。notice
- 次要错误。success
- 成功。warning
- 警告。sql_field
- SQL 中的模型字段名称。sql_coltype
- SQL 中的模型字段类型。sql_keyword
- SQL 关键字。sql_table
- SQL 中的模型名称。http_info
- 1XX HTTP 信息服务器响应。http_success
- 2XX HTTP 成功服务器响应。http_not_modified
- 304 HTTP 未修改服务器响应。http_redirect
- 3XX HTTP 重定向服务器响应(304 除外)。http_not_found
- 404 HTTP 找不到服务器响应。http_bad_request
- 除 404 以外的 4XX HTTP 错误请求服务器响应。http_server_error
- 5XX HTTP 服务器错误响应。migrate_heading
- 迁移管理命令中的标题。migrate_label
- 迁移名称。
这些角色中的每一个都可以分配一个特定的前景色和背景色,从以下列表中
黑色
红色
绿色
黄色
蓝色
品红色
青色
白色
然后可以使用以下显示选项修改这些颜色中的每一个
粗体
下划线
闪烁
反转
隐藏
颜色规范遵循以下模式之一
role=fg
role=fg/bg
role=fg,option,option
role=fg/bg,option,option
其中 role
是有效颜色角色的名称,fg
是前景色,bg
是背景色,每个 option
是颜色修改选项之一。然后用分号分隔多个颜色规范。例如
export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
将指定使用蓝色背景上的闪烁黄色显示错误,并使用品红色显示通知。所有其他颜色角色将保持无色。
还可以通过扩展基本调色板来指定颜色。如果在颜色规范中放入调色板名称,则将加载该调色板暗示的所有颜色。所以
export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
将指定使用浅色调色板中的所有颜色,除了错误和通知的颜色,这些颜色将按指定进行覆盖。
Bash 补全¶
如果您使用 Bash shell,请考虑安装 Django bash 补全脚本,它位于 Django 源发行版中的 extras/django_bash_completion 中。它启用 django-admin
和 manage.py
命令的制表符补全,因此您可以,例如...
- 键入
django-admin
。 - 按 [TAB] 查看所有可用选项。
- 键入
sql
,然后按 [TAB],查看所有名称以sql
开头的可用选项。
请参阅 如何创建自定义 django-admin 命令,了解如何添加自定义操作。
Black 格式化¶
由 startproject
、startapp
、optimizemigration
、makemigrations
和 squashmigrations
创建的 Python 文件使用 black
命令进行格式化,如果它存在于您的 PATH
中。
如果您已全局安装 black
,但不想将其用于当前项目,则可以显式设置 PATH
PATH=path/to/venv/bin django-admin makemigrations
对于使用 stdout
的命令,您可以根据需要将输出管道传输到 black
django-admin inspectdb | black -
从代码运行管理命令¶
-
django.core.management.
call_command
(name, *args, **options)¶
要从代码调用管理命令,请使用 call_command()
。
name
- 要调用的命令的名称或命令对象。除非对象是必需的用于测试,否则首选传递名称。
*args
- 命令接受的参数列表。参数传递给参数解析器,因此您可以使用与在命令行中相同的样式。例如,
call_command('flush', '--verbosity=0')
。 **options
- 命令行中接受的命名选项。选项传递给命令,而不会触发参数解析器,这意味着您需要传递正确的类型。例如,
call_command('flush', verbosity=0)
(零必须是整数,而不是字符串)。
示例
from django.core import management
from django.core.management.commands import loaddata
management.call_command("flush", verbosity=0, interactive=False)
management.call_command("loaddata", "test_data", verbosity=0)
management.call_command(loaddata.Command(), "test_data", verbosity=0)
请注意,不带参数的命令选项作为关键字传递,其中 True
或 False
,如您在上面的 interactive
选项中所看到的。
可以通过使用以下语法之一传递命名参数
# Similar to the command line
management.call_command("dumpdata", "--natural-foreign")
# Named argument similar to the command line minus the initial dashes and
# with internal dashes replaced by underscores
management.call_command("dumpdata", natural_foreign=True)
# `use_natural_foreign_keys` is the option destination variable
management.call_command("dumpdata", use_natural_foreign_keys=True)
使用 call_command()
而非 django-admin
或 manage.py
时,某些命令选项具有不同的名称。例如,django-admin createsuperuser --no-input
转换为 call_command('createsuperuser', interactive=False)
。要查找 call_command()
要使用的关键字参数名称,请检查命令源代码中传递给 parser.add_argument()
的 dest
参数。
采用多个选项的命令选项会传递一个列表
management.call_command("dumpdata", exclude=["contenttypes", "auth"])
call_command()
函数的返回值与命令的 handle()
方法的返回值相同。
输出重定向¶
请注意,你可以重定向标准输出和错误流,因为所有命令都支持 stdout
和 stderr
选项。例如,你可以编写
with open("/path/to/command_output", "w") as f:
management.call_command("dumpdata", stdout=f)