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.

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

--database DATABASE

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

diffsettings

django-admin diffsettings

Отображает различия между текущим файлом настроек и стандартными настройками Django.

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

--all

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

--database DATABASE

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

loaddata

django-admin loaddata fixture [fixture ...]

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

--database DATABASE

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

--ignorenonexistent, -i

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

--app APP_LABEL

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

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

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

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.

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

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

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

Указывает интерпретатор shell. По умолчанию 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__)"

showmigrations

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

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

--list, -l

Выводит список всех известных Django приложений, доступных миграций для каждого приложения и применена ли каждая миграция (маркируется как [X] рядом с именем миграции).

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

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

--plan, -p

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

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

--liveserver LIVESERVER

Переопределяет значение по умолчанию адреса, откуда ожидается запуск сервера живого тестирования (используемого с LiveServerTestCase). Значение по умолчанию localhost:8081-8179.

--noinput, --no-input

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

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

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

--keepdb, -k

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

--reverse, -r

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

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

ogrinspect

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

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

django.contrib.sessions

clearsessions

django-admin clearsessions

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

django.contrib.sitemaps

ping_google

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

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

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 Not Modified (код 304).
• http_redirect - ответ сервера HTTP Redirect (код 3XX, кроме 304).
• http_not_found - ответ сервера HTTP Not Found (код 404).
• http_bad_request - ответ сервера HTTP Bad Request (код 4XX, кроме 404).
• http_server_error - ответ сервера HTTP Server Error (код 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)

Параметры команд, принимающие несколько параметров, передаются в виде списка:

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)