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]

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

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

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

--database DATABASE

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

--include-views

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

loaddata

django-admin loaddata fixture [fixture ...]

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

--database DATABASE

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

--ignorenonexistent, -i

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

--app APP_LABEL

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

--format FORMAT

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

--exclude EXCLUDE, -e EXCLUDE

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

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

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

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

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

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

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

django-admin loaddata mydata.json

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

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

django-admin loaddata mydata

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

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

django-admin loaddata foo/bar/mydata.json

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

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

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

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

post_save.connect(my_handler, sender=MyModel)

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

from functools import wraps

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

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

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

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

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

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

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

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

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

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

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

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

• bold
• underscore
• blink
• reverse
• conceal

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

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

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

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

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

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

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

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

Автозаполнение bash

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

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

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

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

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)