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

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). Вы даже можете сделать это частью вашего набора интеграционных тестов.

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

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

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

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

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

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) ни одной миграции.

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

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

--list, -l

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

--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}, -i {ipython,bpython}

Указывает оболочку для использования. По умолчанию Django будет использовать IPython или bpython, если какой-либо из них установлен. Если оба установлены, укажите нужный, как показано ниже:

IPython:

django-admin shell -i ipython

bpython:

django-admin shell -i bpython

--plain

Если у вас установлен богатый интерпретатор, но вы хотите принудительно использовать обычный интерпретатор Python, используйте опцию --plain, как показано ниже:

django-admin shell --plain

--nostartup

Отключает чтение файла запуска для обычного интерпретатора Python. По умолчанию читается скрипт, указанный в переменной среды PYTHONSTARTUP или скрипт ~/.pythonrc.py.

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.

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

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

См. его description в документации Sitemaps.

django.contrib.staticfiles

collectstatic

Эта команда доступна только если установлено приложение приложений статических файлов (django.contrib.staticfiles).

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

findstatic

Эта команда доступна только если установлено приложение приложений статических файлов (django.contrib.staticfiles).

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

Стандартные опции

Хотя некоторые команды могут иметь свои собственные пользовательские опции, каждая команда поддерживает следующие опции:

--pythonpath PYTHONPATH

Добавляет указанный путь к файловой системе в путь поиска импорта Python. Если этот параметр не указан, django-admin будет использовать переменную окружения PYTHONPATH.

Эта опция не требуется в manage.py, так как она сама позаботится о настройке пути Python.

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

django-admin migrate --pythonpath='/home/djangoprojects/myproject'

--settings SETTINGS

Указывает модуль настроек, который нужно использовать. Модуль настроек должен быть в синтаксисе Python-пакетов, например, mysite.settings. Если этот параметр не указан, django-admin будет использовать переменную окружения DJANGO_SETTINGS_MODULE.

Эта опция не требуется в manage.py, поскольку она по умолчанию использует settings.py из текущего проекта.

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

django-admin migrate --settings=mysite.settings

--traceback

Отображает полный стек вызовов при возникновении CommandError. По умолчанию, django-admin отобразит простое сообщение об ошибке при возникновении CommandError и полный стек вызовов для любых других исключений.

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

django-admin migrate --traceback

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

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

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

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

django-admin migrate --verbosity 2

--no-color

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

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

django-admin runserver --no-color

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

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

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

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

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

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

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

export DJANGO_COLORS="light"

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

• error - Главная ошибка.
• notice - Незначительная ошибка.
• success - Успех.
• warning - Предупреждение.
• sql_field - Имя поля модели в SQL.
• sql_coltype - Тип поля модели в SQL.
• sql_keyword - Ключевое слово SQL.
• sql_table - Имя модели в SQL.
• http_info - Информационный HTTP-ответ сервера 1XX.
• http_success - Успешный HTTP-ответ сервера 2XX.
• http_not_modified - HTTP-ответ сервера 304 (Не изменено).
• 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, рассмотрите установку скрипта автодополнения Bash для Django, который находится в 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
management.call_command('flush', verbosity=0, interactive=False)
management.call_command('loaddata', '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'])

Перенаправление вывода

Обратите внимание, что вы можете перенаправлять стандартные потоки вывода и ошибок, так как все команды поддерживают опции stdout и stderr. Например, вы можете написать:

with open('/path/to/command_output') as f:
    management.call_command('dumpdata', stdout=f)