Как отобразить помощь¶

django-admin help¶

Выполните django-admin help, что бы увидеть помощь и список доступных команд.

Выполните django-admin help --commands, чтобы увидеть список доступных команд.

Выполните django-admin help <command>, чтобы увидеть описание указанной команды и список доступных опций.

Названия приложений¶

Большая часть команд принимает список «названий приложений». «Название приложения» – это название основного пакета приложения. Например, если настройка INSTALLED_APPS содержит строку 'mysite.blog', название приложения будет blog.

Получаем текущую версию Django¶

django-admin version¶

Выполните django-admin version, чтобы получить текущую версию Django.

Вывод соответствует схеме, описанной в PEP 440:

1.4.dev17026
1.4a1
1.4

Вывод отладочной информации¶

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

black¶

django-admin check [app_label [app_label ...]]¶

Использует приложение проверки, чтобы проанализировать проект Django на наличие распространенных проблем.

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

django-admin check auth admin myapp

--tag TAGS, -t TAGS¶

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

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

--database DATABASE¶

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

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

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

--list-tags¶

Выводит список всех доступных тегов.

--deploy¶

Опция --deploy выполняет дополнительные проверки, которые уместны только для настроек сервера, а не окружения для разработки.

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

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

Вы можете использовать эту опцию на «боевом» или тестовом сервере (без --settings). Вы даже можете сделать проверку частью тестов.

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

Указывает уровень сообщения, при котором команда завершится с ненулевым статусом. По умолчанию установлено ОШИБКА.

compilemessages¶

django-admin compilemessages¶

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

--locale LOCALE, -l LOCALE¶

Опция --locale или -l позволяет указать локаль, которая будет использоваться при выполнении команды.

--exclude EXCLUDE, -x EXCLUDE¶

Опция :djadminopt:`--exclude` (или короткий вариант -x) позволяет исключить локали из обработки. Если не указана, ни одна локаль не будет исключена.

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

Опция --ignore или -i позволяет игнорировать файлы или каталоги, которые соответствуют указанному шаблону в стиле glob. Можно указать несколько раз.

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

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

createcachetable¶

django-admin createcachetable¶

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

--database DATABASE¶

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

--dry-run¶

Опция :djadminopt:`--dry-run` выведет SQL, который выполнился бы, без его выполнения. Вы можете изменить его или использовать миграции.

dbshell¶

django-admin dbshell¶

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

• Для PostgreSQL используется консольный клиент psql .

• Для MySQL используется mysql.

• Для SQLite используется sqlite3.

• Для Oracle запустит консольный клиент sqlplus.

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

--database DATABASE¶

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

-- ARGUMENTS¶

Любые аргументы после разделителя -- будут переданы базовому клиенту командной строки. Например, в PostgreSQL вы можете использовать флаг -c команды psql для прямого выполнения необработанного SQL-запроса:

$ django-admin dbshell -- -c 'select current_user'
 current_user
--------------
 postgres
(1 row)

...\> django-admin dbshell -- -c 'select current_user'
 current_user
--------------
 postgres
(1 row)

В MySQL/MariaDB это можно сделать с помощью флага -e команды mysql:

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

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

diffsettings¶

django-admin diffsettings¶

Показывает разницу между текущими настройками и настройками Django по умолчанию.

Настройки, которые не указаны в настройках по умолчанию, выводятся с "###" в конце. Например, в настройках по умолчанию не указан ROOT_URLCONF, и в выводе diffsettings, к ROOT_URLCONF будет добавлен "###" в конце.

--all¶

Опция :djadminopt:`--all` позволяет вывести все настройки, даже если они не отличаются от настроек по умолчанию. Такие настройки выводятся с префиксом "###".

--default MODULE¶

Показывает разницу между текущими настройками и настройками Django по умолчанию.

--output {hash,unified}¶

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

magenta¶

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

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

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

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

Когда результат dumpdata сохраняется в виде файла, он может служить фикстурой для tests или как начальными данными.

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

--all, -a¶

Опция :djadminopt:`--all` позволяет указать dumpdata использовать базовый менеджер Django, чтобы исключить фильтрацию данных собственным менеджером модели.

--format FORMAT¶

Указывает формат сериализации выходных данных. По умолчанию JSON. Поддерживаемые форматы перечислены в Форматы сериализации.

--indent INDENT¶

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

--exclude EXCLUDE, -e EXCLUDE¶

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

Если вы хотите исключить несколько приложений, передайте --exclude несколько раз:

django-admin dumpdata --exclude=auth --exclude=contenttypes

--database DATABASE¶

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

--natural-foreign¶

Если указана эта опция, Django будут использовать метод связанной модели natural_key() для внешних ключей и связей многое-ко-многим. Если вы делаете дамп contrib.auth Permission или contrib.contenttypes ContentType, вам следует использовать эту опцию. Подробности смотрите в разделе о натуральных ключах.

--natural-primary¶

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

--pks PRIMARY_KEYS¶

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

--output OUTPUT, -o OUTPUT¶

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

Если эта опция установлена ​​и --verbosity больше 0 (по умолчанию), в терминале отображается индикатор выполнения.

django-admin dumpdata -o mydata.json.gz

flush¶

django-admin flush¶

Удаляет все данные из базы данных, запускает «post-synchronization» обработчики. Таблица с выполненными миграциями не очищается.

Если вы предпочитаете начать с пустой базы данных и повторно выполнить все миграции, вам следует удалить и воссоздать базу данных, а затем вместо этого запустить migrate.

--noinput, --no-input¶

Подавляет все запросы пользователя.

--database DATABASE¶

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

inspectdb¶

django-admin inspectdb [table [table ...]]¶

Анализирует таблицы в базе данных, указанной настройкой NAME, и выводит сгенерированные модели Django (файл models.py) в стандартный вывод.

Вы можете выбрать, какие таблицы или представления проверять, передав их имена в качестве аргументов. Если аргументы не указаны, модели для представлений создаются только в том случае, если используется опция --include-views. Модели для таблиц разделов создаются в PostgreSQL, если используется опция --include-partitions.

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

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

• Если inspectdb не может подобрать подходящий тип поля модели, будет использоваться поле TextField с комментарием в коде 'This field type is a guess.' возле этого поля.

• Если название колонки в таблице входит в зарезервированные слова Python (такие как 'pass', 'class' или 'for'), inspectdb добавит '_field' к названию атрибута. Например, если таблица содержит колонку 'for', сгенерированная модель будет содержать поле 'for_field', с параметром db_column равным 'for'. inspectdb добавит комментарий в коде 'Field renamed because it was a Python reserved word.' возле поля.

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

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

По умолчанию inspectdb создает неуправляемые модели. То есть с managed=False``в классе ``Meta модели, что указывает Django не управляет созданием, изменением или удалением таблицы. Чтобы позволить Django управлять моделью, установите параметр managed в True (или просто удалите его, True является значением по умолчанию).

magenta¶

django-admin loaddata fixture [fixture ...]¶

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

--database DATABASE¶

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

--ignorenonexistent, -i¶

Опция :djadminopt:`--ignorenonexistent` позволяет игнорировать отсутствие полей в модели и моделей, если они были удалены после создания фикстуры.

--app APP_LABEL¶

Опция :djadminopt:`--app` позволяет указать приложение, которое будет использоваться для поиска фикстур. Без этой опции фикстуры ищутся во всех приложениях.

--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 (в каталоге проекта) или каталоге переводов (для проекта или приложения). Чтобы использовать файлы перевода с помощью gettext, необходимо их скомпилировать командой compilemessages. Смотрите раздел о i18n

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

--all, -a¶

Используйте опцию --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¶

Опция :djadminopt:`--exclude` (или короткий вариант -x) позволяет исключить локали из обработки. Если не указана, ни одна локаль не будет исключена.

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

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¶

Опция --symlinks или -s позволяет указать следовать ли по символическим ссылкам при поиске файлов.

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

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

--ignore PATTERN, -i PATTERN¶

Опция --ignore или -i позволяет игнорировать файлы или каталоги, которые соответствуют указанному шаблону в стиле glob. Можно указать несколько раз.

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

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

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

--no-default-ignore¶

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

--no-wrap¶

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

--no-location¶

Опция --no-location позволяет отключить добавление „#: filename:line’ в файлы перевода. Обратите внимание, использование этой опции может усложнить работу технически образованным переводчикам, которым такие комментарии помогают понять смысл переводимого сообщения.

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

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

• full (по умолчанию, если не указано): строки включают как имя файла, так и номер строки.

• файл: номер строки опущен.

• никогда: строки подавляются (аналогично --no-location).

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

--no-obsolete¶

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

--keep-pot¶

Опция --keep-pot указывает Django не удалять временные .pot файлы, которые создаются перед созданием .po файлов. Это полезно при отладке ошибок, которые мешают созданию файлов перевода.

makemigrations [<app_label>]¶

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

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

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

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

--noinput, --no-input¶

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

--empty¶

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

--dry-run¶

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

--merge¶

Опция --merge позволяет исправить конфликты в миграциях.

--name NAME, -n NAME¶

Опция --name позволяет указать миграции название.

--no-header¶

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

--check¶

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

--scriptable¶

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

--update¶

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

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

white¶

django-admin migrate [app_label] [migration_name]¶

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

Поведение команды зависит от указанных аргументов:

• Без аргументов: будет выполнена синхронизация всех приложений.

• <app_label>: Будут выполнены миграции для указанного приложения до самой последней миграции. Это может вызвать миграцию других приложений через зависимости в миграциях.

• <app_label> <migrationname>: Приводит базу данных к состоянию, которые было бы после завершения указанной миграции, но последующие миграции не выполнены. Обратите внимание, это может привести к отмене миграций, если были выполнены миграции, которые следуют после указанной вами. Используйте zero, чтобы отменить все миграции для приложения.

--database DATABASE¶

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

--fake¶

Опция --fake указывает Django пометить миграции как выполненные/невыполненные без выполнения каких-либо SQL запросов.

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

--fake-initial¶

Опция --fake-initial позволяет Django пропустить начальную миграцию, если уже существуют все таблицы для моделей, которые указанны в операциях :class:`~django.db.migrations.operations.CreateModel`миграции. Эта опция создана для первого выполнения миграции на базе данных, которая существовала до создания миграций. Однако, эта опция не выполняет проверки соответствия структуры таблиц и моделей, поэтому следует использовать её, если вы уверены в правильности миграций.

--plan¶

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

--run-syncdb¶

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

--noinput, --no-input¶

Подавляет все запросы пользователя. Пример запроса спрашивает об удалении устаревших типов контента.

--check¶

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

--prune¶

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

оптимизировать миграцию¶

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

--noreload¶

Опция --noreload позволяет отключить автоматическую перезагрузку сервера при изменении Python файлов.

--nothreading¶

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

--ipv6, -6¶

Опция --ipv6 (или короткий вариант -6) указывает Django использовать IPv6. IP адрес по умолчанию 127.0.0.1 будет заменен на ::1.

DJANGO_RUNSERVER_HIDE_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, имеют приоритет. Также импортируются следующие распространенные утилиты:

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

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

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

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

Django использует IPython или bpython, если они установлены. Если вы хотите использовать «обычный» интерпретатор Python, укажите опцию --plain:

IPython:

django-admin shell -i ipython

бпитон:

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() на этой платформе.

**options¶

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

Показывает все миграции в проекте.

--list, -l¶

Опция --list выведет все активированные приложения в проекте, список доступных миграций и пометки были ли они выполнены (знак [X] возле названия миграции).

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

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

--plan, -p¶

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

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

--database DATABASE¶

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

sqlflush¶

django-admin sqlflush¶

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

--database DATABASE¶

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

white¶

django-admin sqlmigrate app_label migration_name¶

Выводит в консоль SQL запросы для указанной миграции. Требует активного подключения к базе данных, чтобы определить доступны имена constraint(FIXME). Это значит, что вы должны создать SQL для копии базы данных, к которой будут применяться запросы.

Обратите внимание, sqlmigrate не использует цветной вывод в консоль.

--backwards¶

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

--database DATABASE¶

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

sqlsequencereset¶

django-admin sqlsequencereset app_label [app_label ...]¶

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

Эти счетчики используются для определения следующего доступного номера.

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

--database DATABASE¶

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

сквошмиграции¶

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 пытается оптимизировать операции в миграциях, чтобы уменьшить размер файла. Опция --no-optimize позволяет отключить такое поведение, если оптимизация привела к созданию неправильной миграции, или ошибке при выполнении команды. Также мы просим сообщить об этом в баг-трекере Django.

--noinput, --no-input¶

Подавляет все запросы пользователя.

--squashed-name SQUASHED_NAME¶

Устанавливает имя сжатой миграции. Если этот параметр опущен, имя основано на первой и последней миграции с _squashed_ между ними.

--no-header¶

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

стартап¶

django-admin startapp name [directory]¶

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

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

Если указан необязательный пункт назначения, Django будет использовать вместо него это имя. Если каталог с данным именем не существует, он будет создан. Вы можете использовать „.“ для обозначения текущего рабочего каталога.

Например:

django-admin startapp myapp /Users/jezdez/Code/myapp

--template TEMPLATE¶

Опция --template позволяет указать путь к своему шаблону приложения. Вы можете указать путь к каталогу или архиву (.tar.gz, .tar.bz2, .tgz, .tbz, .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__ или начинающиеся с . будут исключены.

Контекст шаблона <django.template.Context>`, используемый для всех соответствующих файлов:

• Все опции, переданные при вызове команды startapp (только поддерживаемые этой командой)

• app_name – название приложение, указанное при вызове команды

• app_directory – полный путь к созданному приложению

• camel_case_app_name – название приложение в «camel case» формате

• docs_version – версия документации: 'dev' или '1.x'

• docs_version – версия документации: 'dev' или '1.x'

стартпроект¶

django-admin startproject name [directory]¶

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

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

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

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

Например:

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

--template TEMPLATE¶

Specifies a directory, file path, or URL of a custom project template. See the startapp --template documentation for examples and usage. Здесь применимы те же соображения безопасности, описанные для шаблонов startapp: вредоносные или плохо сконструированные шаблоны могут иметь слабые места или потреблять чрезмерные ресурсы, поэтому перед использованием шаблоны следует тщательно проверять.

--extension EXTENSIONS, -e EXTENSIONS¶

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

--name FILES, -n FILES¶

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

--exclude DIRECTORIES, -x DIRECTORIES¶

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

Используемый контекст шаблона:

• Все опции, переданные при вызове команды startproject (только поддерживаемые этой командой)

• project_name – название проекта, указанное при вызове команды

• project_directory – полный путь к созданному проекту

• secret_key – случайный ключ для настройки SECRET_KEY

• docs_version – версия документации: 'dev' или '1.x'

• docs_version – версия документации: 'dev' или '1.x'

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

тест¶

django-admin test [test_label [test_label ...]]¶

Выполняет тесты для всех установленных моделей(FIXME: models?). Смотрите Тестирование в Django.

--failfast¶

Опция --failfast позволяет остановить выполнение тестов после первой ошибки.

--testrunner TESTRUNNER¶

Опция --testrunner позволяет указать класс исполнителя тестов, который будет использоваться для запуска тестов. Указанное значение переопределяет значение настройки TEST_RUNNER.

--noinput, --no-input¶

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

$ python -m pip install tblib

тестовый сервер¶

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

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

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

django-admin testserver mydata.json

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

1. Создаст тестовую базу данных, как описано вы Тестовая база данных.

2. Добавит в нее данных из указанных фикстур. (Подробности о фикстурах смотрите в описании loaddata.)

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

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

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

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

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

--addrport 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 с тестовым приспособлением:

django-admin testserver --addrport 1.2.3.4:7000 test

--noinput, --no-input¶

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

django.contrib.auth¶

django-admin changepassword ringo

django.contrib.sitemaps¶

django.contrib.gis¶

django.contrib.sessions¶

django.contrib.staticfiles¶

Подсветка синтаксиса¶

DJANGO_COLORS¶

Команды django-admin / manage.py использует цветной вывод, если терминал поддерживает ANSI-цветной вывод. Если вывод передается в другую команду через «pipe»(|), цветной выводе не будет использоваться.

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 о том, как добавить свои команды.

Черное форматирование¶

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

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

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

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

django-admin inspectdb | black -