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 — в фреймворке кэша 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 вы можете использовать флаг 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 |
+----------------------+

diffsettings

django-admin diffsettings

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

Настройки, отсутствующие в стандартных настройках, следуют за "###". Например, в стандартных настройках не определён ROOT_URLCONF, поэтому ROOT_URLCONF следует за "###" в выводе diffsettings.

--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. Подробную информацию см. в документации по i18n.

Для этой команды не требуются настроенные настройки. Однако, если настройки не настроены, команда не может игнорировать директории MEDIA_ROOT и STATIC_ROOT или включать LOCALE_PATHS.

--all, -a

Обновляет файлы сообщений для всех доступных языков.

--extension EXTENSIONS, -e EXTENSIONS

Указывает список расширений файлов для проверки (по умолчанию: html, txt, py или js если --domain равно js).

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

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

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 для миграции до самого начала, т. е. для отмены всех применённых миграций для приложения.

--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 и выше.

При запуске сервера, и каждый раз при изменении кода 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 contrib включено (по умолчанию в новых проектах), команда runserver будет переопределена собственной командой runserver.

Журналирование каждого запроса и ответа сервера отправляется в логгер django.server.

--noreload

Отключает автоматическую перезагрузку. Это означает, что любые изменения в Python-коде, которые вы внесли во время работы сервера, не вступят в силу, если соответствующие Python-модули уже загружены в память.

--nothreading

Отключает использование потоков на сервере разработки. По умолчанию сервер многопоточный.

--ipv6, -6

Использует IPv6 для сервера разработки. Это изменяет адрес по умолчанию с 127.0.0.1 на ::1.

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

Порт 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 в режиме разработки

Команда runserver Django предоставляет 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.

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

--nostartup

Отключает чтение скрипта запуска для обычного интерпретатора 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 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 для отмены миграции. По умолчанию генерируется 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-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 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'

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 TEMPLATE

Указывает каталог, путь к файлу или URL-адрес пользовательского шаблона проекта. См. документацию startapp --template для примеров и использования.

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

Устанавливает настройку 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 уменьшит число процессов соответственно.

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

Для правильного отображения строк отслеживания требуется пакет третьей стороны tblib.

$ python -m pip install tblib

Эта функция недоступна в Windows. Она также не работает с бэкендом Oracle.

Если вы хотите использовать pdb для отладки тестов, необходимо отключить параллельное выполнение (--parallel=1). В противном случае вы увидите что-то вроде bdb.BdbQuit.

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

findstatic

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

Пожалуйста, обратитесь к его description в документации по статическим файлам.

Параметры по умолчанию

Хотя некоторые команды могут иметь собственные пользовательские параметры, все команды по умолчанию допускают следующие параметры:

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

• Установите colorama, пакет Python, который преобразует коды ANSI в вызовы API Windows. Команды 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 — информационный ответ сервера 1XX HTTP.
• http_success — успешный ответ сервера 2XX HTTP.
• http_not_modified — ответ сервера 304 HTTP Not Modified.
• http_redirect — ответ сервера 3XX HTTP Redirect, кроме 304.
• http_not_found — ответ сервера 404 HTTP Not Found.
• http_bad_request — ответ сервера 4XX HTTP Bad Request, кроме 404.
• http_server_error — ответ сервера 5XX HTTP 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, поэтому вы можете, например...

• Написать 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)