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.

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.' рядом с полем в сгенерированной модели.
• Если имя столбца базы данных является зарезервированным словом 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

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

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

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

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

Позволяет назначать имя(а) сгенерированной миграции(ям) вместо использования сгенерированного имени.

--exit, -e

Заставляет makemigrations завершиться с кодом ошибки 1, когда миграции не создаются (или не были бы созданы, если это комбинировано с --dry-run).

--check

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

migrate

django-admin migrate [app_label] [migration_name]

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

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

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

--database DATABASE

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

--fake

Указывает Django пометить миграции как применённые или отменённые, но без фактического выполнения 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.

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

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

Запрещает все запросы пользователю.

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 — имя приложения в формате camelCase
• docs_version — версия документации: 'dev' или '1.x'

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'

Также см. предупреждение об рендеринге, как упомянуто для 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, которое реализует их. Этот раздел описывает их, сгруппированные по приложениям.

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 (приложение типов содержимого django.contrib.contenttypes).

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

--database DATABASE

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

django.contrib.gis

ogrinspect

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

См. её description в документации GeoDjango.

django.contrib.sessions

clearsessions

django-admin clearsessions

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

django.contrib.sitemaps

ping_google

Эта команда доступна только при установке фреймворка Sitemaps (фреймворк 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"

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

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