django-admin и manage.py

django-admin — утилита командной строки Django для административных задач. В этом документе описаны все её возможности.

Кроме того, manage.py автоматически создается в каждом проекте Django. Она выполняет те же действия, что и django-admin, но также устанавливает переменную среды DJANGO_SETTINGS_MODULE, чтобы она указывала на файл settings.py вашего проекта.

Скрипт django-admin должен быть в пути вашей системы, если вы установили Django через pip. Если его нет в пути, убедитесь, что активирована ваша виртуальная среда.

В целом, при работе с одним проектом Django проще использовать manage.py вместо django-admin. Если вам нужно переключаться между несколькими файлами настроек Django, используйте django-admin с DJANGO_SETTINGS_MODULE или опцией командной строки --settings.

В примерах командной строки в этом документе используется django-admin, но любой пример может использовать manage.py или python -m django с таким же успехом.

Использование

$ django-admin <command> [options]
$ manage.py <command> [options]
$ python -m django <command> [options]

...\> django-admin <command> [options]
...\> manage.py <command> [options]
...\> py -m django <command> [options]

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

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

django-admin help

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

Запустите django-admin help --commands для отображения списка всех доступных команд.

Запустите django-admin help <command> для отображения описания данной команды и списка доступных опций.

Имена приложений

Многие команды принимают список «имен приложений». «Имя приложения» — это имя базовой части пакета, содержащего ваши модели. Например, если ваш INSTALLED_APPS содержит строку 'mysite.blog', то имя приложения — blog.

Определение версии

django-admin version

Запустите django-admin version для отображения текущей версии Django.

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

1.4.dev17026
1.4a1
1.4

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

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

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

check

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

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

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

django-admin check auth admin myapp

--tag TAGS, -t TAGS

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

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

--database DATABASE

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

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

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

--list-tags

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

--deploy

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

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

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

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

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

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

compilemessages

django-admin compilemessages

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

--locale LOCALE, -l LOCALE

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

--exclude EXCLUDE, -x EXCLUDE

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

--use-fuzzy, -f

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

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

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

--ignore PATTERN, -i PATTERN

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

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

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

createcachetable

django-admin createcachetable

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

--database DATABASE

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

--dry-run

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

dbshell

django-admin dbshell

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

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

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

--database DATABASE

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

-- ARGUMENTS

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

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

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

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

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

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

diffsettings

django-admin diffsettings

Отображает различия между текущим файлом настроек и стандартными настройками Django (или другим файлом настроек, указанным параметром --default).

Настройки, отсутствующие в стандартных, сопровождаются "###". Например, стандартные настройки не определяют ROOT_URLCONF, поэтому ROOT_URLCONF сопровождается "###" в выводе diffsettings.

--all

Отображает все настройки, даже если они имеют значение по умолчанию Django. Такие настройки предваряются "###".

--default MODULE

Модуль настроек для сравнения с текущими настройками. Оставьте пустым для сравнения со стандартными настройками Django.

--output {hash,unified}

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

dumpdata

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

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

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

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

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

--all, -a

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

--format FORMAT

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

--indent INDENT

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

--exclude EXCLUDE, -e EXCLUDE

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

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

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

--database DATABASE

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

--natural-foreign

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

--natural-primary

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

--pks PRIMARY_KEYS

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

--output OUTPUT, -o OUTPUT

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

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

Сжатие фикстур

Файл вывода можно сжать в одном из форматов bz2, gz, lzma, или xz, добавив соответствующее расширение к имени файла. Например, чтобы вывести данные в сжатый файл JSON:

django-admin dumpdata -o mydata.json.gz

flush

django-admin flush

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

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

--noinput, --no-input

Отключает все запросы пользователю.

--database DATABASE

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

inspectdb

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

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

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

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

Как можно ожидать, созданные модели будут иметь атрибут для каждого поля в таблице. Обратите внимание, что inspectdb имеет несколько специальных случаев в выводе имени поля:

• Если inspectdb не может сопоставить тип столбца с типом поля модели, он будет использовать TextField и вставит Python-комментарий 'This field type is a guess.' рядом с полем в сгенерированной модели. Распознаваемые поля могут зависеть от приложений, перечисленных в INSTALLED_APPS. Например, django.contrib.postgres добавляет распознавание нескольких типов полей, специфичных для PostgreSQL.
• Если имя столбца базы данных является зарезервированным словом Python (например, 'pass', 'class' или 'for'), inspectdb добавит '_field' к имени атрибута. Например, если таблица имеет столбец 'for', сгенерированная модель будет иметь поле 'for_field', с атрибутом db_column установленным в 'for'. inspectdb вставит Python-комментарий 'Field renamed because it was a Python reserved word.' рядом с полем.

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

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

По умолчанию inspectdb создаёт необработанные модели. То есть, managed = False в классе модели Meta сообщает Django, что не нужно управлять созданием, изменением и удалением каждой таблицы. Если вам нужно, чтобы Django управлял жизненным циклом таблицы, вам нужно изменить опцию managed на True (или убрать её, так как True — это её значение по умолчанию).

Примечания для различных баз данных

Oracle

• Модели создаются для материализованных представлений, если используется --include-views.

PostgreSQL

• Модели создаются для внешних таблиц.
• Модели создаются для материализованных представлений, если используется --include-views.
• Модели создаются для разбиений таблиц, если используется --include-partitions.

--database DATABASE

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

--include-partitions

Если этот параметр указан, модели также создаются для партиций.

Реализована только поддержка PostgreSQL.

--include-views

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

loaddata

django-admin loaddata fixture [fixture ...]

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

--database DATABASE

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

--ignorenonexistent, -i

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

--app APP_LABEL

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

--format FORMAT

Указывает формат сериализации (например, json или xml) для фикстур, считанных из стандартного ввода.

--exclude EXCLUDE, -e EXCLUDE

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

Что такое «фикстура»?

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

Django будет искать фикстуры в трёх местах:

1. В каталоге fixtures каждого установленного приложения
2. В любом каталоге, указанном в настройке FIXTURE_DIRS
3. По указанному пути фикстуры

Django загрузит все найденные фикстуры, соответствующие указанным именам.

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

django-admin loaddata mydata.json

будут загружены только JSON-фикстуры с названием mydata. Расширение фикстуры должно соответствовать зарегистрированному имени сериализатора (например, json или xml).

Если вы опустите расширение, Django будет искать соответствующую фикстуру всех доступных типов. Например:

django-admin loaddata mydata

будет искать любую фикстуру любого типа с названием mydata. Если каталог фикстур содержал mydata.json, эта фикстура была бы загружена как JSON-фикстура.

Имена фикстур могут включать компоненты каталога. Эти каталоги будут включены в путь поиска. Например:

django-admin loaddata foo/bar/mydata.json

будет искать <app_label>/fixtures/foo/bar/mydata.json для каждого установленного приложения, <dirname>/foo/bar/mydata.json для каждого каталога в FIXTURE_DIRS, и буквальный путь foo/bar/mydata.json.

При обработке файлов фикстур данные сохраняются в базе данных как есть. Определённые в модели методы save() не вызываются, и любые сигналы pre_save или post_save будут вызваны с raw=True, так как экземпляр содержит только атрибуты, локальные для модели. Например, вы можете захотеть отключить обработчики, которые обращаются к связанным полям, отсутствующим во время загрузки фикстур и, в противном случае, вызывающим исключение:

from django.db.models.signals import post_save
from .models import MyModel

def my_handler(**kwargs):
    # disable the handler during fixture loading
    if kwargs['raw']:
        return
    ...

post_save.connect(my_handler, sender=MyModel)

Вы также можете написать декоратор для инкапсуляции этой логики:

from functools import wraps

def disable_for_loaddata(signal_handler):
    """
    Decorator that turns off signal handlers when loading fixture data.
    """
    @wraps(signal_handler)
    def wrapper(*args, **kwargs):
        if kwargs['raw']:
            return
        signal_handler(*args, **kwargs)
    return wrapper

@disable_for_loaddata
def my_handler(**kwargs):
    ...

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

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

Команда dumpdata может использоваться для генерации входных данных для loaddata.

Сжатые фикстуры

Фикстуры могут быть сжаты в формате zip, gz, bz2, lzma, или xz. Например:

django-admin loaddata mydata.json

будет искать любую из mydata.json, mydata.json.zip, mydata.json.gz, mydata.json.bz2, mydata.json.lzma, или mydata.json.xz. Используется первый файл в сжатом архиве.

Обратите внимание, что если будут обнаружены две фикстуры с одинаковым именем, но разными типами фикстур (например, если mydata.json и mydata.xml.gz были найдены в одном каталоге фикстур), установка фикстуры будет прервана, и любые данные, установленные в вызове loaddata, будут удалены из базы данных.

Фикстуры, специфичные для базы данных

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

Например, если в настройке DATABASES определена база данных «users», назовите фикстуру mydata.users.json или mydata.users.json.gz, и фикстура будет загружена только при указании загрузки данных в базу данных users.

Загрузка фикстур из стандартного ввода

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

django-admin loaddata --format=json -

При чтении из стандартного ввода, необходим параметр --format для указания формата сериализации входных данных (например, json или xml).

Загрузка из стандартного ввода полезна при перенаправлении стандартного ввода и вывода. Например:

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

makemessages

django-admin makemessages

Обрабатывает всю дерево каталогов текущего каталога и извлекает все строки, помеченные для перевода. Создаёт (или обновляет) файл сообщений в каталоге conf/locale (в дереве Django) или locale (для проекта и приложения). После внесения изменений в файлы сообщений необходимо скомпилировать их с помощью compilemessages для использования с встроенной поддержкой gettext. Подробности см. в документации i18n.

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

--all, -a

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

--extension EXTENSIONS, -e EXTENSIONS

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

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

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

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

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

--locale LOCALE, -l LOCALE

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

--exclude EXCLUDE, -x EXCLUDE

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

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

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

--domain DOMAIN, -d DOMAIN

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

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

--symlinks, -s

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

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

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

--ignore PATTERN, -i PATTERN

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

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

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

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

--no-default-ignore

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

--no-wrap

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

--no-location

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

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

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

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

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

--keep-pot

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

makemigrations

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

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

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

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

--noinput, --no-input

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

--empty

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

--dry-run

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

--merge

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

--name NAME, -n NAME

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

--no-header

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

--check

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

--scriptable

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

migrate

django-admin migrate [app_label] [migration_name]

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

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

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

--database DATABASE

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

--fake

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

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

--fake-initial

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

--plan

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

--run-syncdb

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

--noinput, --no-input

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

--check

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

--prune

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

optimizemigration

django-admin optimizemigration app_label migration_name

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

--check

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

runserver

django-admin runserver [addrport]

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

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

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

НЕ ИСПОЛЬЗУЙТЕ ЭТОТ СЕРВЕР В ПРОИЗВОДСТВЕННОЙ СРЕДЕ. Он не прошёл аудит безопасности или тестирование производительности. (И так будет оставаться. Мы занимаемся разработкой веб-фреймворков, а не веб-серверов, поэтому улучшение этого сервера для обработки производственной среды выходит за рамки Django.)

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

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

При запуске сервера и каждом изменении кода Python во время работы сервера, система проверит весь ваш проект Django на наличие распространённых ошибок (см. команду check). Если будут обнаружены ошибки, они будут выведены в стандартный вывод. Вы можете использовать опцию --skip-checks для пропуска выполнения системных проверок.

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

Обратите внимание, что по умолчанию IP-адрес 127.0.0.1 недоступен с других машин в вашей сети. Чтобы сделать ваш сервер разработки доступным для других машин в сети, используйте собственный IP-адрес (например, 192.168.2.1) или 0.0.0.0 или :: (с поддержкой IPv6).

Вы можете указать 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 для предоставления статических медиа-файлов, прочитайте Как управлять статическими файлами (например, изображениями, 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

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

django-admin shell -i python

--nostartup

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

--command COMMAND, -c COMMAND

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

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

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

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

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

showmigrations

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

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

--list, -l

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

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

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

--plan, -p

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

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

--database DATABASE

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

sqlflush

django-admin sqlflush

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

--database DATABASE

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

sqlmigrate

django-admin sqlmigrate app_label migration_name

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

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

--backwards

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

--database DATABASE

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

sqlsequencereset

django-admin sqlsequencereset app_label [app_label ...]

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

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

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

--database DATABASE

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

squashmigrations

django-admin squashmigrations app_label [start_migration_name] migration_name

Сжимает миграции для app_label до и включая migration_name вниз до меньшего количества миграций, если это возможно. Результирующие сжатые миграции могут безопасно существовать вместе с несжатыми. Для получения дополнительной информации, пожалуйста, прочитайте Сжатие миграций.

Если указано start_migration_name, Django включит только миграции, начиная с и включая эту миграцию. Это помогает смягчить ограничение сжатия для миграций RunPython и django.db.migrations.operations.RunSQL.

--no-optimize

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

--noinput, --no-input

Отключает все запросы пользователю.

--squashed-name SQUASHED_NAME

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

--no-header

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

startapp

django-admin startapp name [directory]

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

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

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

Например:

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

--template TEMPLATE

Указывает путь к каталогу с пользовательским файлом шаблона приложения или пути к нераспакованному архиву (.tar) или сжатому архиву (.tar.gz, .tar.bz2, .tar.xz, .tar.lzma, .tgz, .tbz2, .txz, .tlz, .zip) содержащим файлы шаблона приложения.

Например, это позволит найти шаблон приложения в указанном каталоге при создании приложения myapp:

django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp

Django также принимает URL (http, https, ftp) для сжатых архивов с файлами шаблона приложения, загружая и извлекая их на лету.

Например, используя возможность GitHub по отображению репозиториев в виде zip-файлов, вы можете использовать URL, подобный:

django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/main.zip myapp

--extension EXTENSIONS, -e EXTENSIONS

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

--name FILES, -n FILES

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

--exclude DIRECTORIES, -x DIRECTORIES

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

Контекст template context, используемый для всех соответствующих файлов:

• Любой параметр, переданный команде startapp (среди поддерживаемых параметров команды)
• app_name – имя приложения, переданное команде
• app_directory – полный путь к новосозданному приложению
• camel_case_app_name – имя приложения в формате с заглавной буквы
• docs_version – версия документации: 'dev' или '1.x'
• django_version – версия Django, например '2.0.3'

startproject

django-admin startproject name [directory]

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

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

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

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

Например:

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

--template TEMPLATE

Указывает каталог, путь к файлу или URL-адрес пользовательского шаблона проекта. См. документацию startapp --template для примеров и использования.

--extension EXTENSIONS, -e EXTENSIONS

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

--name FILES, -n FILES

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

--exclude DIRECTORIES, -x DIRECTORIES

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

Используемый template context:

• Любой параметр, переданный команде startproject (среди поддерживаемых параметров команды)
• project_name – имя проекта, переданное команде
• project_directory – полный путь к новосозданному проекту
• secret_key – случайный ключ для настройки SECRET_KEY
• docs_version – версия документации: 'dev' или '1.x'
• django_version – версия Django, например '2.0.3'

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

test

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

Запускает тесты для всех установленных приложений. Подробнее см. Тестирование в Django.

--failfast

Останавливает выполнение тестов и сообщает об ошибке сразу после ее обнаружения.

--testrunner TESTRUNNER

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

--noinput, --no-input

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

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

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

--keepdb

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

--shuffle [SEED]

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

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

--reverse, -r

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

--debug-mode

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

--debug-sql, -d

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

--parallel [N]

DJANGO_TEST_PROCESSES

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

Использование --parallel без значения или со значением auto запускает один процесс теста на ядро в соответствии с multiprocessing.cpu_count(). Вы можете переопределить это, передав нужное количество процессов, например, --parallel 4, или установив переменную среды DJANGO_TEST_PROCESSES.

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

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

Для корректного отображения трассировок этого параметра требуется пакет tblib сторонних разработчиков:

$ python -m pip install tblib

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

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

--tag TAGS

Запускает только те тесты, которые помечены указанными тегами. Можно указать несколько раз и комбинировать с test --exclude-tag.

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

--exclude-tag EXCLUDE_TAGS

Исключает тесты помеченные указанными тегами. Можно указать несколько раз и комбинировать с test --tag.

-k TEST_NAME_PATTERNS

Запускает тестовые методы и классы, соответствующие шаблонам имен тестов, аналогично unittest's -k option. Можно указать несколько раз.

--pdb

Запускает отладчик pdb при каждой ошибке или сбое теста. Если он установлен, вместо него используется ipdb.

--buffer, -b

Отбрасывает вывод (stdout и stderr) для прохождения тестов аналогично unittest's --buffer option.

--no-faulthandler

Django автоматически вызывает faulthandler.enable() при запуске тестов, что позволяет выводить трассировку стека при аварийном завершении интерпретатора. Используйте --no-faulthandler для отключения этого поведения.

--timing

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

testserver

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

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

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

django-admin testserver mydata.json

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

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

Это полезно в ряде случаев:

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

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

--addrport ADDRPORT

Указывает другой порт или IP-адрес и порт, отличные от значения по умолчанию 127.0.0.1:8000. Это значение имеет точно такой же формат и выполняет точно такую же функцию, как аргумент команды runserver.

Примеры:

Запуск тестового сервера на порте 7000 с fixture1 и fixture2:

django-admin testserver --addrport 7000 fixture1 fixture2
django-admin testserver fixture1 fixture2 --addrport 7000

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

Запуск на 1.2.3.4:7000 с test фикстурой:

django-admin testserver --addrport 1.2.3.4:7000 test

--noinput, --no-input

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

Команды, предоставляемые приложениями

Некоторые команды доступны только тогда, когда приложение django.contrib , реализующее их, было enabled. Этот раздел описывает их, сгруппированные по приложениям.

django.contrib.auth

changepassword

django-admin changepassword [<username>]

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

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

--database DATABASE

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

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

django-admin changepassword ringo

createsuperuser

django-admin createsuperuser

DJANGO_SUPERUSER_PASSWORD

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

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

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

В неинтерактивном режиме USERNAME_FIELD и необходимые поля (перечисленные в REQUIRED_FIELDS) используют переменные окружения DJANGO_SUPERUSER_<uppercase_field_name>, если они не переопределены аргументом командной строки. Например, чтобы предоставить поле email, вы можете использовать переменную окружения DJANGO_SUPERUSER_EMAIL.

--noinput, --no-input

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

--username USERNAME

--email EMAIL

Имя пользователя и адрес электронной почты для новой учётной записи могут быть предоставлены с помощью аргументов --username и --email в командной строке. Если ни один из них не указан, createsuperuser запросит их при интерактивном запуске.

--database DATABASE

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

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

django.contrib.contenttypes

remove_stale_contenttypes

django-admin remove_stale_contenttypes

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

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

--database DATABASE

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

--include-stale-apps

Удаляет устаревшие типы содержимого, включая типы из ранее установленных приложений, удалённых из INSTALLED_APPS. По умолчанию False.

django.contrib.gis

ogrinspect

Эта команда доступна только в том случае, если установлена GeoDjango (django.contrib.gis).

Обратитесь к её description в документации GeoDjango.

django.contrib.sessions

clearsessions

django-admin clearsessions

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

django.contrib.sitemaps

ping_google

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

Обратитесь к его description в документации Sitemaps.

django.contrib.staticfiles

collectstatic

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

Обратитесь к его description в документации staticfiles.

findstatic

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

Обратитесь к его description в документации staticfiles.

Основные параметры

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

--pythonpath PYTHONPATH

Добавляет заданный путь к файловой системе в путь поиска импорта Python. Если это не указано, django-admin будет использовать переменную окружения PYTHONPATH.

Этот параметр не нужен в manage.py, так как он сам устанавливает путь к Python.

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

django-admin migrate --pythonpath='/home/djangoprojects/myproject'

--settings SETTINGS

Указывает модуль настроек, который нужно использовать. Модуль настроек должен быть в синтаксисе Python-пакета, например mysite.settings. Если это не указано, django-admin будет использовать переменную окружения DJANGO_SETTINGS_MODULE.

Этот параметр не нужен в manage.py, так как он по умолчанию использует settings.py из текущего проекта.

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

django-admin migrate --settings=mysite.settings

--traceback

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

Этот параметр игнорируется runserver.

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

django-admin migrate --traceback

--verbosity {0,1,2,3}, -v {0,1,2,3}

Указывает количество сообщений и отладочной информации, которое команда должна выводить в консоль.

• 0 означает отсутствие вывода.
• 1 означает обычный вывод (по умолчанию).
• 2 означает подробный вывод.
• 3 означает очень подробный вывод.

Этот параметр игнорируется runserver.

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

django-admin migrate --verbosity 2

--no-color

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

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

django-admin runserver --no-color

--force-color

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

--skip-checks

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

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

django-admin migrate --skip-checks

Дополнительные возможности

Синтаксическая подсветка

DJANGO_COLORS

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

Поддержка Windows

В Windows 10 приложения Windows Terminal, VS Code и PowerShell (где включена обработка виртуального терминала) поддерживают цветной вывод по умолчанию.

В Windows, старая консоль cmd.exe не поддерживает ANSI-последовательности, поэтому по умолчанию цветной вывод отсутствует. В этом случае вам необходимы сторонние библиотеки:

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

  ...\> py -m pip install colorama
  

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

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

Настройка цветов

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

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

Вы выбираете палитру, установив переменную среды DJANGO_COLORS для указания желаемой палитры. Например, чтобы указать палитру light в оболочке 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 - Информационный ответ сервера HTTP (1XX).
• http_success - Ответ сервера HTTP (2XX).
• http_not_modified - Ответ сервера HTTP (304).
• http_redirect - Переадресация сервера HTTP (3XX, кроме 304).
• http_not_found - Ответ сервера HTTP (404).
• http_bad_request - Ошибка запроса сервера HTTP (4XX, кроме 404).
• http_server_error - Ошибка сервера HTTP (5XX).
• migrate_heading - Заголовок в команде управления миграциями.
• migrate_label - Имя миграции.

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

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

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

• bold
• underscore
• blink
• reverse
• conceal

Запись цвета следует одному из следующих шаблонов:

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

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

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

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

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

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

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

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

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

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

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

Форматирование Black

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

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

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

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

django-admin inspectdb | black -

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

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)