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.

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

--output {hash,unified}

Указывает формат вывода. Доступные значения — hash и unified. hash — это режим по умолчанию, который отображает вывод, описанный выше. unified отображает вывод, аналогичный diff -u . Настройки по умолчанию предваряются знаком минус, а изменённые настройки — знаком плюс.

dumpdata

django-admin dumpdata [app_label[.ModelName] [app_label[.ModelName] ...]]

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

Если имя приложения не указано, будут выгружены все установленные приложения.

Вывод dumpdata может быть использован в качестве входных данных для loaddata.

Если результат dumpdata сохранён в файле, он может использоваться в качестве fixtures для тестов или в качестве исходных данных.

Обратите внимание, что 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).

Требуется Django gettext 0.19 или новее.

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

--scriptable

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

--update

Объединяет изменения модели в последнюю миграцию и оптимизирует полученные операции.

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

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

--noreload

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

--nothreading

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

--ipv6, -6

Использует IPv6 для сервера разработки. Это меняет IP-адрес по умолчанию с 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 в режиме разработки

Команда 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.

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

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

IPython:

django-admin shell -i ipython

bpython:

django-admin shell -i bpython

Если у вас установлена «оболочка» (rich shell), но вы хотите принудительно использовать обычный интерпретатор 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 – имя приложения в формате с заглавной буквой
• 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]

Случайным образом меняет порядок тестов перед их запуском. Это может помочь в обнаружении тестов, которые не изолированы должным образом. Порядок тестов, сгенерированный этим параметром, является детерминированной функцией заданного целого числа. Если не задан seed, выбирается случайный seed и печатается в консоль. Чтобы повторить определённый порядок тестов, передайте seed. Сгенерированные этим параметром порядки тестов сохраняют гарантии Django на порядке тестов. Они также сохраняют группы тестов по классу тестового случая.

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

--reverse, -r

Сортирует тестовые случаи в обратном порядке выполнения. Это может помочь в отладке побочных эффектов тестов, которые не изолированы должным образом. Группировка по тестовому классу сохраняется при использовании этого параметра. Его можно использовать вместе с --shuffle для изменения порядка для определённого seed.

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

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

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

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

django.contrib.sessions

clearsessions

django-admin clearsessions

Можно запускать как задачу cron или непосредственно для очистки истекших сессий.

django.contrib.sitemaps

ping_google

Эта команда доступна только если установлен фреймворк Sitemaps (django.contrib.sitemaps).

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

django.contrib.staticfiles

collectstatic

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

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

findstatic

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

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

Дополнительные параметры

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

--pythonpath PYTHONPATH

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

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

  ...\> py -m pip install colorama
  

• Установите 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, рассмотрите установку скрипта автодополнения Bash для Django, который находится в 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)