django-admin и manage.py

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

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

Скрипт django-admin должен быть на пути вашей системы, если вы установили Django с помощью pip. Если он не находится в вашем пути, вы можете найти его в site-packages/django/bin вашей установки Python. Рассмотрите возможность создания символической ссылки на него из места в вашем пути, например, /usr/local/bin.

Для пользователей Windows, у которых нет возможности создавать символические ссылки, вы можете скопировать django-admin.exe в место в вашем существующем пути или изменить настройки PATH (в Settings - Control Panel - System - Advanced - Environment...) для указания на его место установки.

В целом, при работе с одним проектом 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

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

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() для сериализации любой связи foreign key и many-to-many в объекты типа, который определяет этот метод. Если вы выгружаете contrib.auth Permission объекты или contrib.contenttypes ContentType объекты, вы, вероятно, должны использовать этот флаг. См. документацию естественных ключей для получения дополнительной информации об этом и следующем параметре.

--natural-primary

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

--pks PRIMARY_KEYS

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

--output OUTPUT, -o OUTPUT

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

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

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) для фикстур читаемых из stdin.

--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. Например:

django-admin loaddata mydata.json

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

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

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

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

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

Загрузка фикстур из stdin

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

django-admin loaddata --format=json -

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

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

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

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

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

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

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). Если какие-либо ошибки будут обнаружены, они будут выведены в стандартный вывод.

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

django-admin runserver

Порт 8000 по адресу 1.2.3.4:

django-admin runserver 1.2.3.4:8000

Порт 7000 по адресу 127.0.0.1:

django-admin runserver 7000

Порт 7000 по адресу 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

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

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

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

--plan, -p

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

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

--database DATABASE

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

sqlflush

django-admin sqlflush

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

--database DATABASE

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

sqlmigrate

django-admin sqlmigrate app_label migration_name

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

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

--backwards

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

--database DATABASE

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

sqlsequencereset

django-admin sqlsequencereset app_label [app_label ...]

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

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

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

--database DATABASE

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

squashmigrations

django-admin squashmigrations app_label [start_migration_name] migration_name

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

Для получения дополнительной информации, пожалуйста, обратитесь к Сжатие миграций.

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

--no-optimize

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

--noinput, --no-input

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

--squashed-name SQUASHED_NAME

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

--no-header

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

startapp

django-admin startapp name [directory]

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

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

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

Например:

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

--template TEMPLATE

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

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

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

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

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

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

--extension EXTENSIONS, -e EXTENSIONS

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

--name FILES, -n FILES

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

Контекст 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) должны быть обработаны с помощью движка шаблонов. По умолчанию пустой список.

Используемый 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

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

--reverse, -r

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

--debug-mode

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

--debug-sql, -d

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

--parallel [N]

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

По умолчанию --parallel запускает один процесс на ядро в соответствии с 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.

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 (django.contrib.auth) установлена.

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

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

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

--noinput, --no-input

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

--username USERNAME

--email EMAIL

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

--database DATABASE

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

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

django.contrib.contenttypes

remove_stale_contenttypes

django-admin remove_stale_contenttypes

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

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

--database DATABASE

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

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

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

django-admin migrate --traceback

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

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

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

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

django-admin migrate --verbosity 2

--no-color

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

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

django-admin runserver --no-color

--force-color

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

--skip-checks

Пропускает выполнение системных проверок перед выполнением команды. Этот параметр доступен только в том случае, если атрибут команды requires_system_checks установлен в значение True.

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

django-admin migrate --skip-checks

Дополнительные удобства

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

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

В Windows родная консоль не поддерживает ANSI-escape-последовательности, поэтому по умолчанию цветной вывод отсутствует. Но вы можете установить сторонний инструмент ANSICON, тогда Django-команды обнаружат его и будут использовать его для окрашивания вывода так же, как и на Unix-платформах.

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

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

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

export DJANGO_COLORS="light"

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

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

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

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)