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

Отображение вывода отладки

Use --verbosity, where it is supported, to specify the amount of notification and debug information that django-admin prints to the console.

Доступные команды

check

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

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

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

django-admin check auth admin myapp
--tag TAGS, -t TAGS

Система проверки выполняет множество различных типов проверок, которые относятся к категории categorized with 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

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

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

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

Примечание

Имейте в виду, что не все опции, установленные в OPTIONS части конфигурации вашей базы данных в DATABASES, передаются клиенту командной строки, например, 'isolation_level'.

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 сохраняется в файл, он может служить в качестве fixture для tests или в качестве initial data.

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

--all, -a

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

--format FORMAT

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

--indent INDENT

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

--exclude EXCLUDE, -e EXCLUDE

Prevents specific applications or models (specified in the form of app_label.ModelName) from being dumped. If you specify a model name, then only that model will be excluded, rather than the entire application. You can also mix application names and model names.

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

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

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

--natural-foreign

Использует метод модели natural_key() для сериализации любого внешнего ключа и отношения «многие-ко-многим» к объектам типа, определяющего этот метод. Если вы сбрасываете contrib.auth Permission объекты или contrib.contenttypes ContentType объекты, вам, вероятно, следует использовать этот флаг. Подробнее об этом и следующем параметре см. в документации natural keys.

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

Удаляет все данные из базы данных и повторно выполняет все обработчики постсинхронизации. Таблица, к которой были применены миграции, не очищается.

If you would rather start from an empty database and rerun all migrations, you should drop and recreate the database and then run migrate instead.

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

Searches for and loads the contents of the named fixture into the database.

--database DATABASE

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

--ignorenonexistent, -i

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

--app APP_LABEL

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

--format FORMAT

Указывает serialization format (например, json или xml) для фиксаторов read from stdin.

--exclude EXCLUDE, -e EXCLUDE

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

Загрузка приспособлений из stdin

Вы можете использовать тире в качестве имени приспособления для загрузки ввода из sys.stdin. Например:

django-admin loaddata --format=json -

При чтении из stdin, опция --format необходима для указания serialization 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 documentation.

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

--all, -a

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

--extension EXTENSIONS, -e EXTENSIONS

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

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

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

Разделите несколько расширений запятыми или используйте -e или --extension несколько раз:

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

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

--exclude EXCLUDE, -x EXCLUDE

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

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

django-admin makemessages --locale=pt_BR
django-admin makemessages --locale=pt_BR --locale=fr
django-admin makemessages -l pt_BR
django-admin makemessages -l pt_BR -l fr
django-admin makemessages --exclude=pt_BR
django-admin makemessages --exclude=pt_BR --exclude=fr
django-admin makemessages -x pt_BR
django-admin makemessages -x pt_BR -x fr
--domain DOMAIN, -d DOMAIN

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

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

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

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

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 или новее.

--keep-pot

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

См.также

Смотрите Настройка команды makemessages для инструкций по настройке ключевых слов, которые makemessages передает в xgettext.

makemigrations

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

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

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

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

--noinput, --no-input

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

--empty

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

--dry-run

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

--merge

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

--name NAME, -n NAME

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

--no-header

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

--check

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

Changed in Django 4.2:

В старых версиях недостающие миграции также создавались при использовании опции --check.

--scriptable
New in Django Development version.

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

--update
New in Django 4.2.

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

migrate

django-admin migrate [app_label] [migration_name]

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

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

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

Предупреждение

При неприменении миграций все зависимые миграции также будут неприменены, независимо от <app_label>. Вы можете использовать --plan, чтобы проверить, какие миграции будут отменены.

--database DATABASE

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

--fake

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

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

--fake-initial

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

--plan

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

--run-syncdb

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

--noinput, --no-input

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

--check

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

--prune
New in Django Development version.

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

optimizemigration

New in Django Development version.
django-admin optimizemigration app_label migration_name

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

--check

Makes optimizemigration exit with a non-zero status when a migration can be optimized.

runserver

django-admin runserver [addrport]

Starts a lightweight development web server on the local machine. By default, the server runs on port 8000 on the IP address 127.0.0.1. You can pass in an IP address and port number explicitly.

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

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

DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (And that’s how it’s gonna stay. We’re in the business of making web frameworks, not web servers, so improving this server to be able to handle a production environment is outside the scope of Django.)

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

Если вы используете Linux или MacOS и установили как pywatchman, так и службу Watchman, для автозагрузки сервера будут использоваться сигналы ядра (вместо ежесекундного опроса временных меток модификации файлов). Это позволяет повысить производительность больших проектов, уменьшить время отклика после изменения кода, более надежно обнаруживать изменения и снизить энергопотребление. Django поддерживает pywatchman 1.2.0 и выше.

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

При использовании Watchman с проектом, включающим большие не-Python каталоги, такие как node_modules, рекомендуется игнорировать этот каталог для оптимальной производительности. Смотрите watchman documentation для получения информации о том, как это сделать.

Тайм-аут сторожа

DJANGO_WATCHMAN_TIMEOUT

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

When you start the server, and each time you change Python code while the server is running, the system check framework will check your entire Django project for some common errors (see the check command). If any errors are found, they will be printed to standard output. You can use the --skip-checks option to skip running system checks.

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

Note that the default IP address, 127.0.0.1, is not accessible from other machines on your network. To make your development server viewable to other machines on the network, use its own IP address (e.g. 192.168.2.1), 0 (shortcut for 0.0.0.0), 0.0.0.0, or :: (with IPv6 enabled).

Вы можете указать IPv6-адрес, окруженный скобками (например, [200a::1]:8000). Это автоматически включит поддержку IPv6.

Можно также использовать имя хоста, содержащее только символы ASCII.

Если приложение staticfiles contrib включено (по умолчанию в новых проектах), то команда runserver будет отменена своей собственной командой runserver.

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

--noreload

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

--nothreading

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

--ipv6, -6

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

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

Порт 8000 на IP-адресе 127.0.0.1:

django-admin runserver

Порт 8000 на IP-адресе 1.2.3.4:

django-admin runserver 1.2.3.4:8000

Порт 7000 на IP-адресе 127.0.0.1:

django-admin runserver 7000

Порт 7000 на IP-адресе 1.2.3.4:

django-admin runserver 1.2.3.4:7000

Порт 8000 на IPv6-адресе ::1:

django-admin runserver -6

Порт 7000 на IPv6-адресе ::1:

django-admin runserver -6 7000

Порт 7000 на IPv6-адресе 2001:0db8:1234:5678::9:

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

Порт 8000 на IPv4-адресе хоста localhost:

django-admin runserver localhost:8000

Порт 8000 на IPv6-адресе хоста localhost:

django-admin runserver -6 localhost:8000

Обслуживание статических файлов с помощью сервера разработки

По умолчанию сервер разработки не обслуживает статические файлы для вашего сайта (такие как CSS файлы, изображения, вещи под MEDIA_URL и так далее). Если вы хотите настроить Django на обслуживание статических медиа, прочитайте How to manage static files (e.g. images, JavaScript, CSS).

sendtestemail

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

Отправляет тестовое письмо (для подтверждения того, что отправка писем через Django работает) указанному получателю (получателям). Например:

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

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

--managers

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

--admins

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

shell

django-admin shell

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

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

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

IPython:

django-admin shell -i ipython

bpython:

django-admin shell -i bpython

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

django-admin shell -i python
--nostartup

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

--command COMMAND, -c COMMAND

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

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

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

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

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

showmigrations

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

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

--list, -l

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

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

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

--plan, -p

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

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

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

По умолчанию the new directory содержит файл 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 app:

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'

Предупреждение

Когда файлы шаблонов приложения отрисовываются с помощью шаблонизатора Django (по умолчанию все файлы *.py), Django также заменит все содержащиеся в них переменные шаблона. Например, если один из файлов Python содержит docstring, объясняющий определенную особенность, связанную с рендерингом шаблонов, это может привести к некорректному примеру.

Чтобы обойти эту проблему, вы можете использовать тег шаблона templatetag для «экранирования» различных частей синтаксиса шаблона.

Кроме того, чтобы разрешить файлы шаблонов Python, содержащие синтаксис языка шаблонов Django, а также предотвратить попытки систем упаковки скомпилировать недействительные файлы *.py, файлы шаблонов, заканчивающиеся на .py-tpl, будут переименованы в .py.

Предупреждение

Содержимое шаблонов пользовательских приложений (или проектов) всегда следует проверять перед использованием: Такие шаблоны определяют код, который станет частью вашего проекта, а это значит, что такому коду будут доверять в той же степени, что и любому приложению, которое вы устанавливаете, или коду, который вы пишете сами. Более того, даже рендеринг шаблонов, по сути, является выполнением кода, который был предоставлен в качестве входных данных для команды управления. Язык шаблонов Django может обеспечить широкий доступ в систему, поэтому убедитесь, что любой пользовательский шаблон, который вы используете, достоин вашего доверия.

startproject

django-admin startproject name [directory]

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

По умолчанию the new directory содержит 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'

Please also see the rendering warning and trusted code warning as mentioned for startapp.

test

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

Запускает тесты для всех установленных приложений. Для получения дополнительной информации см. раздел Тестирование в Django.

--failfast

Прекращает выполнение тестов и сообщает о неудаче сразу после того, как тест не прошел.

--testrunner TESTRUNNER

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

--noinput, --no-input

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

Параметры программы тестирования

Команда test получает опции от имени указанного --testrunner. Это опции бегущей строки тестирования по умолчанию: DiscoverRunner.

--keepdb

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

--shuffle [SEED]

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

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

--reverse, -r

Sorts test cases in the opposite execution order. This may help in debugging the side effects of tests that aren’t properly isolated. Grouping by test class is preserved when using this option. This can be used in conjunction with --shuffle to reverse the order for a particular seed.

--debug-mode

Устанавливает значение DEBUG в True перед запуском тестов. Это может помочь в устранении сбоев в тестировании.

--debug-sql, -d

Включает SQL logging для провальных тестов. Если --verbosity равно 2, то запросы в проходящих тестах также выводятся.

--parallel [N]
DJANGO_TEST_PROCESSES

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

Using --parallel without a value, or with the value auto, runs one test process per core according to multiprocessing.cpu_count(). You can override this by passing the desired number of processes, e.g. --parallel 4, or by setting the DJANGO_TEST_PROCESSES environment variable.

Django распределяет тестовые случаи - unittest.TestCase подклассы - по подпроцессам. Если тестовых случаев меньше, чем настроенных процессов, Django соответственно уменьшит количество процессов.

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

Примечание

Если у вас есть тестовые классы, которые нельзя запускать параллельно, вы можете использовать SerializeMixin для их последовательного запуска. См. Enforce running test classes sequentially.

Эта опция требует наличия стороннего пакета tblib для корректного отображения трассировок:

$ python -m pip install tblib

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

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

Предупреждение

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

Это известное ограничение. Оно возникает из-за необходимости сериализации объектов для обмена ими между процессами. Подробности см. в What can be pickled and unpickled?.

--tag TAGS

Выполняет только тесты marked with the specified tags. Может указываться несколько раз и комбинироваться с test --exclude-tag.

Тесты, которые не загружаются, всегда считаются подходящими.

--exclude-tag EXCLUDE_TAGS

Исключает тесты marked with the specified 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() при запуске тестов, что позволяет ему вывести traceback в случае сбоя интерпретатора. Передайте --no-faulthandler, чтобы отключить это поведение.

--timing

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

testserver

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

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

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

django-admin testserver mydata.json

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

  1. Создайте тестовую базу данных, как описано в разделе Тестовая база данных.
  2. Заполнить базу данных тестов данными о приспособлениях из заданных приспособлений. (Подробнее о приспособлениях см. документацию для loaddata выше).
  3. Запускает сервер разработки Django (как в runserver), направленный на эту недавно созданную тестовую базу данных вместо вашей производственной базы данных.

Это полезно в нескольких отношениях:

  • When you’re writing unit tests of how your views act with certain fixture data, you can use testserver to interact with the views in a web browser, manually.
  • Let’s say you’re developing your Django application and have a «pristine» copy of a database that you’d like to interact with. You can dump your database to a fixture (using the dumpdata command, explained above), then use testserver to run your web application with that data. With this arrangement, you have the flexibility of messing up your data in any way, knowing that whatever data changes you’re making are only being made to a test database.

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

django.contrib.auth

changepassword

django-admin changepassword [<username>]

Эта команда доступна только в случае установки authentication system (django.contrib.auth) Django.

Позволяет изменить пароль пользователя. Предлагается дважды ввести новый пароль для данного пользователя. Если они одинаковы, то этот пароль сразу же становится новым. Если пользователь не указан, команда попытается изменить пароль пользователя, имя которого совпадает с именем текущего пользователя.

--database DATABASE

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

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

django-admin changepassword ringo

createsuperuser

django-admin createsuperuser
DJANGO_SUPERUSER_PASSWORD

Эта команда доступна только в случае установки authentication system (django.contrib.auth) Django.

Создает учетную запись суперпользователя (пользователя, обладающего всеми правами). Это полезно, если вам нужно создать начальную учетную запись суперпользователя или если вам нужно программно генерировать учетные записи суперпользователей для вашего сайта (сайтов).

При интерактивном запуске эта команда запросит пароль для новой учетной записи суперпользователя. При неинтерактивном запуске вы можете задать пароль, установив переменную окружения 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 в командной строке. Если ни один из этих аргументов не указан, --email запросит их при интерактивном запуске.

--database DATABASE

Указывает базу данных, в которую будет сохранен объект суперпользователя.

Вы можете подклассифицировать команду управления и переопределить get_input_data(), если хотите настроить ввод и проверку данных. За подробностями о существующей реализации и параметрах метода обратитесь к исходному коду. Например, это может быть полезно, если у вас есть ForeignKey в REQUIRED_FIELDS и вы хотите разрешить создание экземпляра вместо ввода первичного ключа существующего экземпляра.

django.contrib.contenttypes

remove_stale_contenttypes

django-admin remove_stale_contenttypes

Эта команда доступна только в случае установки contenttypes app (django.contrib.contenttypes) Django.

Удаляет устаревшие типы содержимого (из удаленных моделей) в вашей базе данных. Любые объекты, зависящие от удаленных типов содержимого, также будут удалены. Список удаленных объектов будет отображен до того, как вы подтвердите, что удаление разрешено.

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

ping_google

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

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

django.contrib.staticfiles

collectstatic

Эта команда доступна только при установленном static files application (django.contrib.staticfiles).

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

findstatic

Эта команда доступна только при установленном static files application (django.contrib.staticfiles).

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

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

Although some commands may allow their own custom options, every command allows for the following options by default:

--pythonpath PYTHONPATH

Добавляет заданный путь к файловой системе в Python import search 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 (где включена обработка виртуального терминала) допускают цветной вывод и поддерживаются по умолчанию.

Under Windows, the legacy cmd.exe native console doesn’t support ANSI escape sequences so by default there is no color output. In this case either of two third-party libraries are needed:

  • Install colorama, a Python package that translates ANSI color codes into Windows API calls. Django commands will detect its presence and will make use of its services to color output just like on Unix-based platforms. colorama can be installed via pip:

    ...\> py -m pip install colorama
    
  • Install ANSICON, a third-party tool that allows cmd.exe to process ANSI color codes. Django commands will detect its presence and will make use of its services to color output just like on Unix-based platforms.

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

Пользовательские цвета

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

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

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

export DJANGO_COLORS="light"

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

  • error - Крупная ошибка.
  • notice - Незначительная ошибка.
  • success - Успех.
  • warning - Предупреждение.
  • sql_field - Имя поля модели в SQL.
  • sql_coltype - Тип поля модели в SQL.
  • sql_keyword - Ключевое слово SQL.
  • sql_table - Имя модели в SQL.
  • http_info - Ответ сервера 1XX HTTP Informational.
  • http_success - Ответ сервера 2XX HTTP Success.
  • http_not_modified - Ответ сервера 304 HTTP Not Modified.
  • http_redirect - Ответ сервера 3XX HTTP Redirect, отличный от 304.
  • http_not_found - Ответ сервера 404 HTTP Not Found.
  • http_bad_request - Ответ сервера 4XX HTTP Bad Request, отличный от 404.
  • http_server_error - Ответ 5XX HTTP Server Error.
  • migrate_heading - Заголовок в команде управления миграциями.
  • migrate_label - Имя миграции.

Каждой из этих ролей можно присвоить определенный цвет переднего плана и фона из следующего списка:

  • black
  • red
  • green
  • yellow
  • blue
  • magenta
  • cyan
  • white

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

  • bold
  • underscore
  • blink
  • reverse
  • conceal

Спецификация цвета соответствует одной из следующих схем:

  • role=fg
  • role=fg/bg
  • role=fg,option,option
  • role=fg/bg,option,option

где role - имя допустимой цветовой роли, fg - цвет переднего плана, bg - цвет фона и каждый option - одна из опций модификации цвета. Несколько спецификаций цвета разделяются точкой с запятой. Например:

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

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

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

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

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

Завершение Bash

If you use the Bash shell, consider installing the Django bash completion script, which lives in extras/django_bash_completion in the Django source distribution. It enables tab-completion of django-admin and manage.py commands, so you can, for instance…

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

О том, как добавить настраиваемые действия, смотрите How to create custom django-admin commands.

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

New in Django Development version.

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

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

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

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

django-admin inspectdb | black -

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

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

Для вызова команды управления из кода используйте call_command.

name
имя команды для вызова или объект команды. Передача имени предпочтительна, если объект не требуется для тестирования.
*args
список аргументов, принимаемых командой. Аргументы передаются парсеру аргументов, поэтому вы можете использовать тот же стиль, что и в командной строке. Например, call_command('flush', '--verbosity=0').
**options
именованные опции, принимаемые в командной строке. Опции передаются команде без запуска анализатора аргументов, что означает, что вам нужно передать правильный тип. Например, call_command('flush', verbosity=0) (ноль должен быть целым числом, а не строкой).

Примеры:

from django.core import management
from django.core.management.commands import loaddata

management.call_command('flush', verbosity=0, interactive=False)
management.call_command('loaddata', 'test_data', verbosity=0)
management.call_command(loaddata.Command(), 'test_data', verbosity=0)

Обратите внимание, что опции команды, которые не принимают аргументов, передаются как ключевые слова с True или False, как вы можете видеть на примере опции interactive выше.

Именованные аргументы могут быть переданы с помощью одного из следующих синтаксисов:

# Similar to the command line
management.call_command('dumpdata', '--natural-foreign')

# Named argument similar to the command line minus the initial dashes and
# with internal dashes replaced by underscores
management.call_command('dumpdata', natural_foreign=True)

# `use_natural_foreign_keys` is the option destination variable
management.call_command('dumpdata', use_natural_foreign_keys=True)

Некоторые параметры команды имеют другие названия, если использовать call_command() вместо django-admin или manage.py. Например, django-admin createsuperuser --no-input переводится как call_command('createsuperuser', interactive=False). Чтобы узнать, какое имя аргумента ключевого слова следует использовать для call_command(), проверьте в исходном коде команды аргумент dest, передаваемый для parser.add_argument().

Опции команд, которые принимают несколько вариантов, передаются в виде списка:

management.call_command('dumpdata', exclude=['contenttypes', 'auth'])

Возвращаемое значение функции call_command() совпадает с возвращаемым значением метода handle() команды.

Перенаправление выхода

Обратите внимание, что вы можете перенаправить стандартные потоки вывода и ошибок, поскольку все команды поддерживают опции stdout и stderr. Например, вы можете написать:

with open('/path/to/command_output', 'w') as f:
    management.call_command('dumpdata', stdout=f)
Вернуться на верх