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

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 на наличие распространённых проблем.

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

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 (по умолчанию), в терминале отображается полоса прогресса.

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 — его значение по умолчанию).

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). Используйте этот параметр несколько раз для исключения нескольких приложений или моделей.

django-admin loaddata --format=json -

django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -

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

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

--no-obsolete

Удаляет устаревшие строки сообщений из файлов .po.

--keep-pot

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

makemigrations

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

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

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

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

--noinput, --no-input

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

--empty

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

--dry-run

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

--merge

Включает исправление конфликтов миграций.

--name NAME, -n NAME

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

--no-header

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

--check

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

--scriptable

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

--update

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

Обновлённая миграция будет иметь сгенерированное имя. Для сохранения предыдущего имени установите его с помощью --name.

migrate

django-admin migrate [app_label] [migration_name]

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

Поведение этой команды меняется в зависимости от предоставленных аргументов:

• Без аргументов: выполняются все миграции всех приложений.
• <app_label>: выполняются миграции указанного приложения до последней миграции. Это может также потребовать выполнения миграций других приложений из-за зависимостей.
• <app_label> <migrationname>: приводит схему базы данных в состояние, где применена указанная миграция, но не применяются более поздние миграции в том же приложении. Это может потребовать отмены миграций, если вы ранее мигрировали за указанной миграцией. Вы можете использовать префикс имени миграции, например, 0001, при условии, что он уникален для данного имени приложения. Используйте имя zero, чтобы мигрировать полностью назад, т.е. отменить все применённые миграции для приложения.

--database DATABASE

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

--fake

Помечает миграции до целевой (следуя правилам выше) как применённые, но без фактического выполнения SQL для изменения схемы вашей базы данных.

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

--fake-initial

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

--plan

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

--run-syncdb

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

--noinput, --no-input

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

--check

Заставляет migrate завершиться с ненулевым статусом при обнаружении невыполненных миграций.

--prune

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

optimizemigration

django-admin optimizemigration app_label migration_name

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

--check

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

runserver

django-admin runserver [addrport]

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

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

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

Сервер разработки автоматически перезагружает код 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 для сервера разработки. Это изменяет адрес по умолчанию с 127.0.0.1 на ::1.

HIDE_PRODUCTION_WARNING

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

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

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

django-admin runserver

django-admin runserver 1.2.3.4:8000

django-admin runserver 7000

django-admin runserver 1.2.3.4:7000

django-admin runserver -6

django-admin runserver -6 7000

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

django-admin runserver localhost:8000

django-admin runserver -6 localhost:8000

sendtestemail

django-admin sendtestemail [email [email ...]]

Отправляет тестовое электронное письмо (чтобы подтвердить, что отправка электронных писем через Django работает) получателю(ям), указанному.

Например:

django-admin sendtestemail foo@example.com bar@example.com

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

--managers

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

--admins

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

shell

django-admin shell

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

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

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

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

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

IPython:

django-admin shell -i ipython

bpython:

django-admin shell -i bpython

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

django-admin shell -i python

--no-startup

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

--no-imports

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

--command COMMAND, -c COMMAND

Позволяет передать команду в виде строки, чтобы выполнить её как Django, например:

django-admin shell --command="import django; print(django.__version__)"

Вы также можете передать код в стандартный ввод, чтобы выполнить его. Например:

$ django-admin shell <<EOF
> import django
> print(django.__version__)
> EOF

В Windows REPL выводится из-за ограничений реализации select.select() на этой платформе.

showmigrations

django-admin showmigrations [app_label [app_label ...]]

Отображает все миграции в проекте. Вы можете выбрать один из двух форматов:

--list, -l

Выводит список всех известных Django приложений, доступных миграций для каждого приложения и применённых миграций (помечается [X] рядом с именем миграции). Для версии --verbosity 2 и выше также отображаются даты и время применения.

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

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

--plan, -p

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

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

--database DATABASE

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

sqlflush

django-admin sqlflush

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

--database DATABASE

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

sqlmigrate

django-admin sqlmigrate app_label migration_name

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

Обратите внимание, что sqlmigrate не форматирует свой вывод цветом.

--backwards

Генерирует SQL для отмены миграции. По умолчанию создаваемый 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

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

$ python -m pip install tblib

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

django-admin changepassword ringo

django.contrib.contenttypes

django.contrib.gis

django.contrib.sessions

django.contrib.staticfiles

Цветной вывод синтаксиса

DJANGO_COLORS

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

export DJANGO_COLORS="light"

export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"

export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"

Автодополнение для Bash

Если вы используете оболочку Bash, рассмотрите установку скрипта автодополнения Django для Bash, который находится в extras/django_bash_completion в дистрибутиве исходного кода Django. Он позволяет выполнять автодополнение команд django-admin и manage.py, например…

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

См. Как создать пользовательские команды django-admin для получения информации о том, как добавить настраиваемые действия.

Форматирование с помощью Black

Файлы Python, созданные командами startproject, startapp, optimizemigration, makemigrations и squashmigrations, форматируются с помощью команды black, если она присутствует в вашей PATH.

Если у вас black установлена глобально, но вы не хотите использовать её для текущего проекта, вы можете явно задать PATH:

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

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

django-admin inspectdb | black -