django-admin и manage.py

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

Кроме того, manage.py автоматически создаётся в каждом проекте Django. manage.py выполняет те же действия, что и django-admin, но выполняет за вас несколько дополнительных действий:

• Он помещает пакет вашего проекта в sys.path.
• Он устанавливает переменную среды DJANGO_SETTINGS_MODULE так, чтобы она указывала на файл settings.py вашего проекта.

Скрипт django-admin должен находиться на пути вашей системы, если вы установили Django через утилиту setup.py. Если его нет на вашем пути, вы можете найти его в 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]

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

createcachetable

django-admin createcachetable

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

--database DATABASE

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

--dry-run

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

dbshell

django-admin dbshell

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

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

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

--database DATABASE

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

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

flush

django-admin flush

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

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

--noinput, --no-input

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

--database DATABASE

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

inspectdb

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

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

Используйте этот инструмент, если у вас есть устаревшая база данных, с которой вы хотели бы использовать 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.' рядом с полем.

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

Первичные ключи автоматически просматриваются для PostgreSQL, MySQL и SQLite, в этих случаях Django вставляет primary_key=True по мере необходимости.

inspectdb работает с PostgreSQL, MySQL и SQLite. Обнаружение внешних ключей работает только в PostgreSQL и с определёнными типами таблиц MySQL.

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

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

--database DATABASE

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

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

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.

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

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

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

Разрешает именовать сгенерированную(ые) миграцию(и) вместо использования сгенерированного имени.

--check

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

migrate

django-admin migrate [app_label] [migration_name]

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

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

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

--database DATABASE

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

--fake

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

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

--fake-initial

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

--run-syncdb

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

--noinput, --no-input

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

runserver

django-admin runserver [addrport]

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

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

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

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

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

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

При запуске сервера и при каждом изменении кода 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 включено (по умолчанию в новых проектах), команда 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

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

Приложения без миграций также перечисляются, но под ними отображается (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_ между ними.

startapp

django-admin startapp name [directory]

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

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

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

Например:

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

--template TEMPLATE

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

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

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

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

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

django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/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, -k

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

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

$ pip install tblib

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

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

--tag TAGS

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

--exclude-tag EXCLUDE_TAGS

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

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

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

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

--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 ( приложение contenttypes (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

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

Синтаксическое выделение

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

В Windows собственная консоль не поддерживает последовательности ANSI, поэтому по умолчанию вывод не цветной. Но вы можете установить стороннюю утилиту 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') as f:
    management.call_command('dumpdata', stdout=f)