Spec-Zone.ru › Django 6.0

django-admin и manage.py

django-admin — это утилита командной строки Django для административных задач. В этом документе описаны все её возможности.

Кроме того, manage.py автоматически создаётся в каждом проекте Django. Она делает то же самое, что и django-admin, но также задаёт переменную окружения DJANGO_SETTINGS_MODULE, указывая в ней на файл settings.py вашего проекта.

Скрипт django-admin должен находиться в системном пути, если вы установили Django с помощью pip. Если его нет в пути, убедитесь, что активировали виртуальное окружение.

Как правило, при работе с одним проектом 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 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

Компилирует файлы .po, созданные командой makemessages, в файлы .mo для использования со встроенной поддержкой gettext. См. раздел Интернационализация и локализация.

--locale LOCALE, -l LOCALE

Указывает обрабатываемые локали. Если значение не задано, обрабатываются все локали.

--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

Указывает базу данных, для которой нужно открыть оболочку. По умолчанию используется default.

-- ARGUMENTS

Все аргументы после разделителя -- передаются клиенту командной строки. Например, в PostgreSQL можно использовать флаг -c команды psql для непосредственного выполнения необработанного 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 это можно сделать с помощью флага -e команды mysql:

$ django-admin dbshell -- -e "select user()"
+----------------------+
| user()               |
+----------------------+
| djangonaut@localhost |
+----------------------+

...\> django-admin dbshell -- -e "select user()"
+----------------------+
| user()               |
+----------------------+
| djangonaut@localhost |
+----------------------+

Примечание

Обратите внимание, что не все параметры, заданные в разделе OPTIONS конфигурации базы данных в DATABASES, передаются клиенту командной строки, например 'isolation_level'.

diffsettings

django-admin diffsettings

Показывает различия между текущим файлом настроек и настройками Django по умолчанию (или другим файлом настроек, указанным с помощью --default).

Настройки, отсутствующие среди настроек по умолчанию, сопровождаются "###". Например, настройки по умолчанию не определяют ROOT_URLCONF, поэтому в выводе команды diffsettings после 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 (по умолчанию), в терминале отображается индикатор выполнения.

Сжатие фикстур

Выходной файл можно сжать в одном из форматов 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. Модели секционированных таблиц в PostgreSQL создаются при использовании опции --include-partitions.

Используйте эту команду, если хотите работать с устаревшей базой данных в 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.'.

Эта функция предназначена для ускорения работы, а не для окончательной генерации моделей. После её выполнения следует самостоятельно проверить созданные модели и внести необходимые изменения. В частности, потребуется изменить порядок моделей, чтобы модели, ссылающиеся на другие модели, располагались правильно.

Django не создаёт значения по умолчанию в базе данных, если для поля модели задан default. Аналогично, значения по умолчанию в базе данных не преобразуются в значения по умолчанию для полей модели и никак не обнаруживаются командой inspectdb.

По умолчанию inspectdb создаёт неуправляемые модели. То есть managed = False в классе Meta модели сообщает 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 ...]

Ищет указанную фикстуру и загружает её содержимое в базу данных.

--database DATABASE

Указывает базу данных, в которую будут загружены данные. По умолчанию используется default.

--ignorenonexistent, -i

Игнорирует поля и модели, которые могли быть удалены после создания фикстуры.

--app APP_LABEL

Указывает одно приложение для поиска фикстур вместо поиска во всех приложениях.

--format FORMAT

Указывает формат сериализации (например, json или xml) для фикстур, считываемых из стандартного потока ввода.

--exclude EXCLUDE, -e EXCLUDE

Исключает загрузку фикстур для указанных приложений и/или моделей (в формате 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. Подробности см. в документации по интернационализации.

Для этой команды не требуется настроенный модуль параметров. Однако без настроенных параметров команда не может исключить каталоги 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 EXCLUDE, -x EXCLUDE

Указывает локали, которые нужно исключить из обработки. Если значение не задано, исключённые локали отсутствуют.

Пример использования:

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 DOMAIN, -d DOMAIN

Указывает домен файлов сообщений. Поддерживаются следующие параметры:

  • django для всех файлов *.py, *.html и *.txt (по умолчанию)
  • djangojs для файлов *.js
--symlinks, -s

Переходит по символическим ссылкам на каталоги при поиске новых строк для перевода.

Пример использования:

django-admin makemessages --locale=de --symlinks
--ignore PATTERN, -i PATTERN

Игнорирует файлы или каталоги, соответствующие шаблону в стиле 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

Запрещает удаление временных файлов .pot, созданных перед созданием файла .po. Это полезно для отладки ошибок, которые могут помешать созданию итоговых языковых файлов.

См. также

Инструкции по настройке ключевых слов, передаваемых командой makemessages команде xgettext, см. в разделе Настройка команды makemessages.

makemigrations

django-admin makemigrations [app_label [app_label ...]]

Создает новые миграции на основе обнаруженных изменений в ваших моделях. Подробно о миграциях, их связи с приложениями и многом другом рассказано в документации по миграциям.

Если передать в качестве аргументов одно или несколько имен приложений, созданные миграции будут ограничены указанными приложениями и всеми необходимыми зависимостями (например, таблицей на другом конце ForeignKey).

Чтобы добавить миграции в приложение, в котором нет каталога migrations, запустите makemigrations, указав app_label приложения.

--noinput, --no-input

Отключает все запросы к пользователю. Если на запрос, который был отключен, нельзя автоматически дать ответ, команда завершится с кодом ошибки 3.

--empty

Создает пустую миграцию для указанных приложений, предназначенную для редактирования вручную. Эта возможность предназначена для опытных пользователей и должна использоваться только в том случае, если вы знакомы с форматом миграций, операциями миграций и зависимостями между миграциями.

--dry-run

Показывает, какие миграции были бы созданы, не записывая файлы миграций на диск. При использовании этого параметра вместе с --verbosity 3 также будут показаны полные файлы миграций, которые были бы записаны.

--merge

Позволяет устранять конфликты миграций.

--name NAME, -n NAME

Позволяет задать имя созданных миграций вместо использования автоматически сгенерированного имени. Имя должно быть допустимым идентификатором Python.

--no-header

Создает файлы миграций без заголовка с версией Django и временной меткой.

--check

Завершает makemigrations с ненулевым кодом, если обнаружены изменения моделей, для которых нет миграций. Подразумевает --dry-run.

--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

Позволяет Django пропустить начальную миграцию приложения, если все таблицы базы данных с именами всех моделей, созданных всеми операциями CreateModel в этой миграции, уже существуют. Этот параметр предназначен для первого запуска миграций в базе данных, существовавшей до начала использования миграций. Однако он не проверяет соответствие схемы базы данных, кроме совпадения имен таблиц, поэтому безопасно использовать его можно только в том случае, если вы уверены, что существующая схема соответствует описанной в начальной миграции.

--plan

Показывает операции миграции, которые будут выполнены командой migrate.

--run-syncdb

Позволяет создавать таблицы для приложений без миграций. Это не рекомендуется, однако в крупных проектах с сотнями моделей платформа миграций иногда работает слишком медленно.

--noinput, --no-input

Отключает все запросы к пользователю. Например, команда может запросить подтверждение удаления устаревших типов содержимого.

--check

Завершает migrate с ненулевым кодом, если обнаружены непримененные миграции.

--prune

Удаляет несуществующие миграции из таблицы django_migrations. Это полезно, если файлы миграций, замененные объединенной миграцией, были удалены. Подробности см. в разделе Объединение миграций.

optimizemigration

django-admin optimizemigration app_label migration_name

Оптимизирует операции указанной миграции и перезаписывает существующий файл. Если миграция содержит функции, которые необходимо скопировать вручную, команда создает новый файл миграции с суффиксом _optimized, предназначенный для замены указанной миграции.

--check

Завершает optimizemigration с ненулевым кодом, если миграцию можно оптимизировать.

runserver

django-admin runserver [addrport]

Запускает на локальном компьютере легковесный веб-сервер для разработки. По умолчанию сервер работает на порту 8000 по IP-адресу 127.0.0.1. Можно явно указать IP-адрес и номер порта.

Если вы запускаете этот скрипт с обычными правами пользователя (что рекомендуется), у вас может не быть доступа к запуску сервера на порту с малым номером. Порты с малыми номерами зарезервированы для суперпользователя (root).

Этот сервер использует объект приложения WSGI, указанный в настройке WSGI_APPLICATION.

Предупреждение

НЕ ИСПОЛЬЗУЙТЕ ЭТОТ СЕРВЕР В ПРОИЗВОДСТВЕ.

Этот легковесный сервер для разработки не проходил проверок безопасности и производительности, поэтому он не подходит для использования в производственной среде. Обеспечение возможности работы этого сервера в производственной среде не входит в задачи 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.

DJANGO_RUNSERVER_HIDE_WARNING
Добавлено в Django 5.2.

По умолчанию в консоль выводится предупреждение о том, что runserver не подходит для производственной среды:

WARNING: This is a development server. Do not use it in a production setting. Use a production WSGI or ASGI server instead.
For more information on production servers see: https://docs.djangoproject.com/en/|version|/howto/deployment/

Задайте этой переменной окружения значение "true", чтобы скрыть предупреждение.

Примеры использования разных портов и адресов

Порт 8000 по IP-адресу 127.0.0.1:

django-admin runserver

Порт 8000 по IP-адресу 1.2.3.4:

django-admin runserver 1.2.3.4:8000

Порт 7000 по IP-адресу 127.0.0.1:

django-admin runserver 7000

Порт 7000 по IP-адресу 1.2.3.4:

django-admin runserver 1.2.3.4:7000

Порт 8000 по IPv6-адресу ::1:

django-admin runserver -6

Порт 7000 по IPv6-адресу ::1:

django-admin runserver -6 7000

Порт 7000 по IPv6-адресу 2001:0db8:1234:5678::9:

django-admin runserver [2001:0db8:1234:5678::9]:7000

Порт 8000 по IPv4-адресу хоста localhost:

django-admin runserver localhost:8000

Порт 8000 по IPv6-адресу хоста localhost:

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 foo@example.com bar@example.com

Есть несколько параметров, которые можно использовать в любых сочетаниях:

--managers

Отправляет письма на адреса, указанные в MANAGERS, с помощью mail_managers().

--admins

Отправляет письма на адреса, указанные в ADMINS, с помощью mail_admins().

shell

django-admin shell

Запускает интерактивный интерпретатор Python.

Все модели из установленных приложений автоматически импортируются в среду оболочки. Модели из приложений, перечисленных раньше в INSTALLED_APPS, имеют приоритет. Также импортируются следующие часто используемые утилиты:

from django.db import connection, reset_queries, models
from django.conf import settings
from django.utils import timezone

При значении --verbosity 2 или выше список автоматически импортируемых объектов будет выведен на экран. Чтобы полностью отключить автоматический импорт, используйте флаг --no-imports.

См. руководство по настройке этого поведения, чтобы добавить или удалить автоматические импорты.

Изменено в Django 5.2:

Добавлен автоматический импорт моделей.

Изменено в Django 6.0:

Добавлен автоматический импорт часто используемых утилит, таких как django.conf.settings.

--interface {ipython,bpython,python}, -i {ipython,bpython,python}

Задает используемую оболочку. По умолчанию Django использует IPython или bpython, если установлен хотя бы один из них. Если установлены оба, укажите нужный, например:

IPython:

django-admin shell -i ipython

bpython:

django-admin shell -i bpython

Если у вас установлена «расширенная» оболочка, но вы хотите принудительно использовать «обычный» интерпретатор Python, задайте имя интерфейса python, например:

django-admin shell -i python
--no-startup

Отключает чтение стартового скрипта для «обычного» интерпретатора Python. По умолчанию читается скрипт, указанный в переменной окружения PYTHONSTARTUP, или скрипт ~/.pythonrc.py.

--no-imports
Добавлено в Django 5.2.

Отключает автоматический импорт моделей из INSTALLED_APPS.

--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 REPL выводится из-за ограничений реализации select.select() на этой платформе.

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

Выводит SQL-запросы, которые были бы выполнены командой flush.

--database DATABASE

Задает базу данных, для которой нужно вывести SQL-запросы. По умолчанию используется default.

sqlmigrate

django-admin sqlmigrate app_label migration_name

Выводит SQL-запросы для указанной миграции. Для этого требуется активное подключение к базе данных, которое используется для определения имен ограничений; следовательно, SQL нужно создавать для копии базы данных, в которой вы впоследствии планируете его выполнять.

Обратите внимание, что sqlmigrate не раскрашивает вывод.

--backwards

Создает SQL-запросы для отмены миграции. По умолчанию создаются запросы для выполнения миграции в прямом направлении.

--database DATABASE

Задает базу данных, для которой нужно создать SQL-запросы. По умолчанию используется default.

sqlsequencereset

django-admin sqlsequencereset app_label [app_label ...]

Выводит 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 6.0:

Добавлено автоматическое создание каталога назначения.

Например:

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

Предупреждение

Шаблоны, предоставленные через --template, используются без изменений. Вредоносные или плохо составленные шаблоны могут создать уязвимости безопасности или привести к непредусмотренному поведению. При распаковке сжатых архивов также могут расходоваться чрезмерные ресурсы, что может привести к сбоям или зависаниям.

Перед использованием содержимое шаблонов следует тщательно проверить.

--extension EXTENSIONS, -e EXTENSIONS

Указывает, какие расширения файлов в шаблоне приложения следует обрабатывать с помощью шаблонизатора. По умолчанию используется py.

--name FILES, -n FILES

Указывает, какие файлы в шаблоне приложения (помимо соответствующих --extension) следует обрабатывать с помощью шаблонизатора. По умолчанию используется пустой список.

--exclude DIRECTORIES, -x DIRECTORIES

Указывает, какие каталоги в шаблоне приложения следует исключить, помимо .git и __pycache__. Если этот параметр не указан, каталоги с именем __pycache__ или начинающиеся с . будут исключены.

template context, используемый для всех соответствующих файлов:

  • Любой параметр, переданный команде startapp (из числа поддерживаемых командой параметров)
  • app_name – имя приложения, переданное команде
  • app_directory – полный путь к созданному приложению
  • camel_case_app_name – имя приложения в формате camel case
  • docs_version – версия документации: 'dev' или '1.x'
  • django_version – версия Django, например '2.0.3'

Предупреждение

При обработке файлов шаблона приложения с помощью шаблонизатора Django (по умолчанию это все файлы *.py) Django также заменит все случайно оставшиеся переменные шаблона. Например, если в одном из файлов Python есть строка документации с пояснением какой-либо особенности обработки шаблонов, это может привести к некорректному примеру.

Чтобы обойти эту проблему, можно использовать тег шаблона templatetag, чтобы «экранировать» различные части синтаксиса шаблонов.

Кроме того, чтобы разрешить использование файлов шаблонов Python, содержащих синтаксис языка шаблонов Django, и при этом не допустить попыток систем упаковки скомпилировать в байт-код некорректные файлы *.py, файлы шаблонов с окончанием .py-tpl будут переименованы в .py.

Предупреждение

Перед использованием содержимое пользовательских шаблонов приложений (или проектов) всегда следует проверять: такие шаблоны определяют код, который станет частью вашего проекта, а значит, ему будут доверять так же, как любому установленному вами приложению или написанному вами коду. Более того, даже обработка шаблонов фактически означает выполнение кода, переданного в качестве входных данных команде управления. Язык шаблонов Django может предоставлять широкий доступ к системе, поэтому используйте только те пользовательские шаблоны, которым можно доверять.

startproject

django-admin startproject name [directory]

Создает структуру каталогов проекта Django с указанным именем в текущем каталоге или в указанном месте назначения.

По умолчанию новый каталог содержит manage.py и пакет проекта (содержащий settings.py и другие файлы).

Если указано только имя проекта, каталог проекта и пакет проекта будут называться <projectname>, а каталог проекта будет создан в текущем рабочем каталоге.

Если указано необязательное место назначения, Django будет использовать это имя в качестве каталога проекта и создаст в нем manage.py и пакет проекта. Если каталог с указанным именем не существует, он будет создан. Чтобы указать текущий рабочий каталог, используйте «.».

Изменено в Django 6.0:

Добавлено автоматическое создание каталога назначения.

Например:

django-admin startproject myproject /Users/jezdez/Code/myproject_repo
--template TEMPLATE

Указывает каталог, путь к файлу или URL-адрес пользовательского шаблона проекта. Примеры и сведения об использовании см. в документации к startapp --template. Здесь применяются те же соображения безопасности, что и для шаблонов startapp: вредоносные или плохо составленные шаблоны могут создавать уязвимости или потреблять чрезмерные ресурсы, поэтому перед использованием шаблоны следует тщательно проверять.

--extension EXTENSIONS, -e EXTENSIONS

Указывает, какие расширения файлов в шаблоне проекта следует обрабатывать с помощью шаблонизатора. По умолчанию используется py.

--name FILES, -n FILES

Указывает, какие файлы в шаблоне проекта (помимо соответствующих --extension) следует обрабатывать с помощью шаблонизатора. По умолчанию используется пустой список.

--exclude DIRECTORIES, -x DIRECTORIES

Указывает, какие каталоги в шаблоне проекта следует исключить, помимо .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'

Также ознакомьтесь с предупреждением об обработке шаблонов и предупреждением о доверенном коде, упомянутыми для startapp.

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

Перед запуском тестов устанавливает значение True для параметра DEBUG. Это может помочь устранить неполадки при сбоях тестов.

--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 может не суметь вывести трассировку исключения. Это затрудняет отладку. Если вы столкнулись с этой проблемой, запустите соответствующий тест без параллельного выполнения, чтобы увидеть трассировку ошибки.

Это известное ограничение. Оно связано с необходимостью сериализовать объекты для обмена между процессами. Подробности см. в разделе Что можно сериализовать и десериализовать с помощью pickle?.

--tag TAGS

Запускает только тесты, помеченные указанными тегами. Параметр можно указать несколько раз и комбинировать с test --exclude-tag.

Тесты, которые не удалось загрузить, всегда считаются соответствующими условиям.

--exclude-tag EXCLUDE_TAGS

Исключает тесты, помеченные указанными тегами. Параметр можно указать несколько раз и комбинировать с test --tag.

-k TEST_NAME_PATTERNS

Запускает методы и классы тестов, соответствующие шаблонам имен тестов, так же, как unittest's -k option. Параметр можно указать несколько раз.

--pdb

Запускает отладчик pdb при каждой ошибке или неудаче теста. Если он установлен, вместо него используется ipdb.

--buffer, -b

Отбрасывает вывод (stdout и stderr) успешно пройденных тестов, так же, как unittest's --buffer option.

--no-faulthandler

При запуске тестов Django автоматически вызывает faulthandler.enable(), что позволяет вывести трассировку, если интерпретатор аварийно завершится. Передайте --no-faulthandler, чтобы отключить это поведение.

--timing

Выводит время выполнения, включая настройку базы данных и общую продолжительность запуска.

--durations N

Показывает N самых медленных тестовых случаев (N=0 — все).

testserver

django-admin testserver [fixture [fixture ...]]

Запускает сервер разработки Django (как и runserver), используя данные из указанных фикстур.

Например, эта команда:

django-admin testserver mydata.json

…выполнит следующие действия:

  1. Создаст тестовую базу данных, как описано в разделе Тестовая база данных.
  2. Заполнит тестовую базу данными из указанных фикстур. (Дополнительные сведения о фикстурах см. выше в документации к команде loaddata.)
  3. Запустит сервер разработки Django (как и runserver), используя только что созданную тестовую базу данных вместо рабочей.

Это может быть полезно во многих случаях:

  • При написании модульных тестов поведения представлений с определенными данными фикстур можно использовать testserver для ручного взаимодействия с представлениями в веб-браузере.
  • Допустим, вы разрабатываете приложение Django и хотите поработать с «чистой» копией базы данных. Можно выгрузить базу данных в фикстуру (с помощью описанной выше команды dumpdata), а затем использовать testserver для запуска веб-приложения с этими данными. Такой подход позволяет изменять данные как угодно, зная, что все изменения затронут только тестовую базу данных.

Обратите внимание, что этот сервер не обнаруживает автоматически изменения в исходном коде Python (в отличие от runserver). Однако он обнаруживает изменения в шаблонах.

--addrport ADDRPORT

Указывает другой порт либо IP-адрес и порт вместо значения по умолчанию 127.0.0.1:8000. Этот параметр имеет точно такой же формат и выполняет точно ту же функцию, что и аргумент команды runserver.

Примеры:

Чтобы запустить тестовый сервер на порту 7000 с параметрами fixture1 и fixture2:

django-admin testserver --addrport 7000 fixture1 fixture2
django-admin testserver fixture1 fixture2 --addrport 7000

(Приведенные выше команды эквивалентны. Мы включили обе, чтобы показать, что не имеет значения, указаны параметры до или после аргументов фикстур.)

Чтобы запустить сервер по адресу 1.2.3.4:7000 с фикстурой test:

django-admin testserver --addrport 1.2.3.4:7000 test
--noinput, --no-input

Отключает все запросы к пользователю. Типичный запрос — предупреждение об удалении существующей тестовой базы данных.

Команды, предоставляемые приложениями

Некоторые команды доступны только тогда, когда приложение django.contrib, которое реализует их, добавлено в enabled. В этом разделе они описаны и сгруппированы по приложениям.

django.contrib.auth

changepassword

django-admin changepassword [<username>]

Эта команда доступна только в том случае, если установлена система аутентификации Django (django.contrib.auth).

Позволяет изменить пароль пользователя. Команда дважды предложит ввести новый пароль для указанного пользователя. Если введённые значения совпадают, этот пароль сразу станет новым. Если пользователь не указан, команда попытается изменить пароль пользователя, имя которого совпадает с именем текущего пользователя.

--database DATABASE

Указывает базу данных, в которой нужно найти пользователя. По умолчанию используется default.

Пример использования:

django-admin changepassword ringo

createsuperuser

django-admin createsuperuser
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(). Подробные сведения о существующей реализации и параметрах метода см. в исходном коде. Например, это может быть полезно, если у вас есть ForeignKey в REQUIRED_FIELDS и вы хотите разрешить создание экземпляра вместо ввода первичного ключа существующего экземпляра.

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

ogrinspect

Эта команда доступна только в том случае, если установлено GeoDjango (django.contrib.gis).

См. description в документации GeoDjango.

django.contrib.sessions

clearsessions

django-admin clearsessions

Команду можно запускать как задание cron или напрямую, чтобы удалять просроченные сеансы.

django.contrib.staticfiles

collectstatic

Эта команда доступна только в том случае, если установлено приложение статических файлов (django.contrib.staticfiles).

См. description в документации по staticfiles.

findstatic

Эта команда доступна только в том случае, если установлено приложение статических файлов (django.contrib.staticfiles).

См. description в документации по 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. По умолчанию django-admin выведет сообщение об ошибке при возникновении CommandError и полную трассировку стека для любого другого исключения.

Этот параметр игнорируется командой 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

Команды django-admin / manage.py выводят красиво оформленный цветной текст, если ваш терминал поддерживает цвета ANSI. Коды цвета не используются, если вывод команды перенаправляется в другую программу, кроме случаев, когда указан параметр --force-color.

Поддержка Windows

В Windows 10 приложение Windows Terminal, VS Code и PowerShell (при включённой обработке виртуального терминала) поддерживают цветной вывод и работают с ним по умолчанию.

В Windows устаревшая собственная консоль cmd.exe не поддерживает управляющие последовательности ANSI, поэтому по умолчанию цветной вывод отсутствует. В этом случае необходима одна из двух сторонних библиотек:

  • Установите colorama — пакет Python, преобразующий коды цвета ANSI в вызовы Windows API. Команды Django обнаружат его и воспользуются его возможностями для цветного вывода, как и на платформах Unix. colorama можно установить с помощью pip:

    ...\> py -m pip install "colorama >= 0.4.6"
  • Установите ANSICON — сторонний инструмент, позволяющий cmd.exe обрабатывать коды цвета ANSI. Команды Django обнаружат его и воспользуются его возможностями для цветного вывода, как и на платформах Unix.

Другие современные терминальные среды Windows, поддерживающие цвета, но не распознаваемые Django автоматически, могут «имитировать» установку ANSICON, задав соответствующую переменную окружения ANSICON="on".

Настраиваемые цвета

Цвета, используемые для подсветки синтаксиса, можно настроить. В Django входят три цветовые палитры:

  • dark, предназначенная для терминалов, отображающих белый текст на чёрном фоне. Это палитра по умолчанию.
  • light, предназначенная для терминалов, отображающих чёрный текст на белом фоне.
  • nocolor, отключающая подсветку синтаксиса.

Чтобы выбрать палитру, задайте переменную окружения DJANGO_COLORS, указав нужную палитру. Например, чтобы выбрать палитру light в оболочке BASH Unix или OS/X, выполните в командной строке следующее:

export DJANGO_COLORS="light"

Также можно настроить используемые цвета. Django определяет ряд ролей, для которых используются цвета:

  • error — серьёзная ошибка.
  • notice — незначительная ошибка.
  • success — успешное выполнение.
  • warning — предупреждение.
  • sql_field — имя поля модели в SQL.
  • sql_coltype — тип поля модели в SQL.
  • sql_keyword — ключевое слово SQL.
  • sql_table — имя модели в SQL.
  • http_info — информационный ответ сервера HTTP 1XX.
  • http_success — успешный ответ сервера HTTP 2XX.
  • http_not_modified — ответ сервера HTTP 304 Not Modified.
  • http_redirect — ответ сервера HTTP 3XX Redirect, кроме 304.
  • http_not_found — ответ сервера HTTP 404 Not Found.
  • http_bad_request — ответ сервера HTTP 4XX Bad Request, кроме 404.
  • http_server_error — ответ сервера HTTP 5XX Server Error.
  • migrate_heading — заголовок команды управления миграциями.
  • migrate_label — имя миграции.

Каждой из этих ролей можно назначить определённый цвет текста и фона из следующего списка:

  • black
  • red
  • green
  • yellow
  • blue
  • magenta
  • cyan
  • white

Каждый из этих цветов затем можно изменить с помощью следующих параметров отображения:

  • bold
  • underscore
  • blink
  • reverse
  • conceal

Спецификация цвета соответствует одному из следующих шаблонов:

  • 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, рассмотрите возможность установки скрипта автодополнения Django для Bash, который находится в extras/django_bash_completion в дистрибутиве исходного кода Django. Он позволяет автоматически дополнять команды django-admin и manage.py клавишей Tab, например:

  • Введите django-admin.
  • Нажмите [TAB], чтобы увидеть все доступные параметры.
  • Введите sql, а затем нажмите [TAB], чтобы увидеть все доступные параметры, имена которых начинаются с sql.

Инструкции по добавлению пользовательских действий см. в разделе Как создавать пользовательские команды django-admin.

Форматирование Black

Файлы Python, созданные командами startproject, startapp, optimizemigration, makemigrations и squashmigrations, форматируются с помощью команды 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(), проверьте исходный код команды и найдите аргумент dest, передаваемый в parser.add_argument().

Параметры команды, принимающие несколько значений, передаются списком:

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)

© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/6.0/ref/django-admin/

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API