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

Использует фреймворк проверки системы system check framework для проверки всего проекта Django на наличие общих проблем.

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

django-admin check auth admin myapp

--tag TAGS, -t TAGS

Фреймворк проверки системы выполняет множество разных проверок, которые категоризированы с метками. Вы можете использовать эти метки для ограничения выполняемых проверок только теми, которые относятся к определённой категории. Например, для выполнения только проверок моделей и совместимости запустите:

django-admin check --tag models --tag compatibility

--database DATABASE

Указывает базу данных для запуска проверок, требующих доступа к базе данных:

django-admin check --database default --database other

По умолчанию эти проверки не выполняются.

--list-tags

Отображает все доступные метки.

--deploy

Активирует дополнительные проверки, которые актуальны только в среде развертывания.

Вы можете использовать эту опцию в локальной среде разработки, но поскольку ваш локальный модуль настроек разработки может не иметь многих настроек производства, вы, вероятно, захотите указать команду check на другой модуль настроек, либо установив переменную окружения DJANGO_SETTINGS_MODULE, либо передав опцию --settings.

django-admin check --deploy --settings=production_settings

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

--fail-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}

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

compilemessages

django-admin compilemessages

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

--locale LOCALE, -l LOCALE

Указывает локаль(и) для обработки. Если не указано, обрабатываются все локали.

--exclude EXCLUDE, -x EXCLUDE

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

--use-fuzzy, -f

Включает нечётко переведённые переводы в скомпилированные файлы.

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

django-admin compilemessages --locale=pt_BR
django-admin compilemessages --locale=pt_BR --locale=fr -f
django-admin compilemessages -l pt_BR
django-admin compilemessages -l pt_BR -l fr --use-fuzzy
django-admin compilemessages --exclude=pt_BR
django-admin compilemessages --exclude=pt_BR --exclude=fr
django-admin compilemessages -x pt_BR
django-admin compilemessages -x pt_BR -x fr

--ignore PATTERN, -i PATTERN

Игнорирует каталоги, соответствующие заданному шаблону в формате glob. Используйте несколько раз, чтобы пропустить больше.

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

django-admin compilemessages --ignore=cache --ignore=outdated/*/locale

createcachetable

django-admin createcachetable

Создаёт таблицы кэша для использования с кешем базы данных на основе информации из файла настроек. Дополнительную информацию см. в разделе фреймворк кэша Django.

--database DATABASE

Указывает базу данных, в которой будут созданы таблицы кэша. По умолчанию — default.

--dry-run

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

dbshell

django-admin dbshell

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

• Для PostgreSQL это запускает клиент командной строки psql.
• Для MySQL это запускает клиент командной строки mysql.
• Для SQLite это запускает клиент командной строки sqlite3.
• Для Oracle это запускает клиент командной строки sqlplus.

Эта команда предполагает, что программы находятся в вашем системном пути PATH, чтобы вызов имени программы (psql, mysql, sqlite3, sqlplus) находил программу в нужном месте. Указать расположение программы вручную невозможно.

--database DATABASE

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

-- ARGUMENTS

Любые аргументы, следующие за разделителем --, будут переданы в подлежащий клиент командной строки. Например, в PostgreSQL вы можете использовать флаг 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 равен djangojs).

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

django-admin makemessages --locale=de --extension xhtml

Укажите несколько расширений через запятые или используйте -e или --extension несколько раз:

django-admin makemessages --locale=de --extension=html,txt --extension xml

--locale LOCALE, -l LOCALE

Указывает локаль(и) для обработки.

--exclude EXCLUDE, -x EXCLUDE

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

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

django-admin makemessages --locale=pt_BR
django-admin makemessages --locale=pt_BR --locale=fr
django-admin makemessages -l pt_BR
django-admin makemessages -l pt_BR -l fr
django-admin makemessages --exclude=pt_BR
django-admin makemessages --exclude=pt_BR --exclude=fr
django-admin makemessages -x pt_BR
django-admin makemessages -x pt_BR -x fr

--domain DOMAIN, -d DOMAIN

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

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

--symlinks, -s

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

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

django-admin makemessages --locale=de --symlinks

--ignore PATTERN, -i PATTERN

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

По умолчанию используются эти шаблоны: 'CVS', '.*', '*~', '*.pyc'.

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

django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html

--no-default-ignore

Отключает значения по умолчанию для --ignore.

--no-wrap

Отключает разделение длинных строк сообщений на несколько строк в языковых файлах.

--no-location

Запрещает запись комментариев ‘#: filename:line’ в языковых файлах. Использование этой опции затрудняет понимание контекста каждого сообщения для технически подкованных переводчиков.

--add-location [{full,file,never}]

Управление комментариями #: filename:line в языковых файлах. Если опция:

• full (по умолчанию, если не задано): строки включают имя файла и номер строки.
• file: номер строки опускается.
• never: строки подавляются (также как --no-location).

Требуется Django 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.

Сервер разработки автоматически перезагружает код 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-адресу %%%CODE_BLOCK_343%%:

django-admin runserver 1.2.3.4:7000

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

django-admin runserver -6

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

django-admin runserver -6 7000

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

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

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

django-admin runserver localhost:8000

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

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

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

django-admin shell -i python

--no-startup

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

Приложения без миграций также перечислены, но под ними выводится (no migrations).

Это формат вывода по умолчанию.

--plan, -p

Отображает план миграций, который Django будет следовать для применения миграций. Как и в --list, применённые миграции отмечены знаком [X]. Для версий --verbosity и выше также будут показаны все зависимости миграции.

Аргументы 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 – имя приложения в формате camelCase
• 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 выбирается случайным образом и отображается в консоли. Чтобы повторить определённый порядок тестов, передайте 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

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

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

Эта команда доступна только если приложение 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-коды цвета в вызовы Windows API. Команды Django определят его наличие и будут использовать его сервисы для раскрашивания вывода, как и на платформах на основе Unix. colorama можно установить через pip:

  ...\> py -m pip install "colorama >= 0.4.6"
  

• Установите ANSICON, стороннее средство, которое позволяет cmd.exe обрабатывать ANSI-коды цвета. Команды Django определят его наличие и будут использовать его сервисы для раскрашивания вывода, как и на платформах на основе Unix.

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

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

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

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

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

export DJANGO_COLORS="light"

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

• error - Ошибка основного уровня.
• notice - Ошибка вспомогательного уровня.
• success - Успех.
• warning - Предупреждение.
• sql_field - Имя поля модели в SQL.
• sql_coltype - Тип поля модели в SQL.
• sql_keyword - Ключевое слово SQL.
• sql_table - Имя модели в SQL.
• http_info - Информационный ответ сервера HTTP 1XX.
• http_success - Ответ сервера HTTP 2XX (Успех).
• http_not_modified - Ответ сервера HTTP 304 (Не изменено).
• http_redirect - Ответ сервера HTTP 3XX (Переадресация), кроме 304.
• http_not_found - Ответ сервера HTTP 404 (Не найдено).
• http_bad_request - Ответ сервера HTTP 4XX (Ошибка запроса), кроме 404.
• http_server_error - Ответ сервера HTTP 5XX (Ошибка сервера).
• 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 глобально установлен, но вы не хотите использовать его для текущего проекта, вы можете явно задать %%%CODE_BLOCK_720%%:

PATH=path/to/venv/bin django-admin makemigrations

Для команд, использующих stdout, вы можете перенаправить вывод в black, если нужно:

django-admin inspectdb | black -

Выполнение команд управления из вашего кода

django.core.management.call_command(name, *args, **options)

Чтобы вызвать команду управления из кода, используйте %%%CODE_BLOCK_726%%.

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)