django-admin и manage.py

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

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

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

Скрипт django-admin должен быть в вашей системной переменной PATH, если вы установили Django с помощью утилиты setup.py. Если он не в вашей переменной PATH, вы можете найти его в site-packages/django/bin в вашей установке Python. Рассмотрите возможность создания символической ссылки на него из некоторого места в вашей переменной PATH, например, /usr/local/bin.

Для пользователей Windows, у которых нет возможности создания символических ссылок, вы можете скопировать django-admin.exe в место в вашей системной переменной PATH или изменить настройки PATH (в Settings - Control Panel - System - Advanced - Environment...) для указания на место его установки.

Как правило, при работе с одним проектом Django легче использовать manage.py , чем django-admin. Если вам нужно переключаться между несколькими файлами настроек Django, используйте django-admin с DJANGO_SETTINGS_MODULE или параметром командной строки --settings.

Примеры команд в этом документе используют django-admin для согласованности, но любой пример может использовать manage.py также.

Использование

$ django-admin <command> [options]
$ manage.py <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 должен выводить в консоль. Более подробную информацию см. в документации к параметру --verbosity.

Доступные команды

check <appname appname ...>

django-admin check

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

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

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

python manage.py check auth admin myapp

Если вы не укажете ни одного приложения, будут проверены все приложения.

--tag <tagname>

Фреймворк проверки системы выполняет множество различных типов проверок. Эти типы проверок категоризируются по меткам. Вы можете использовать эти метки для ограничения выполняемых проверок только проверками в определенной категории. Например, чтобы выполнить только проверки безопасности и совместимости, вы запустите:

python manage.py check --tag security --tag compatibility

--list-tags

Список всех доступных меток.

--deploy

Параметр --deploy активирует некоторые дополнительные проверки, которые актуальны только в среде развертывания.

Вы можете использовать этот параметр в вашей локальной среде разработки, но поскольку ваш локальный файл настроек разработки может не содержать многих ваших настроек для производства, вам, вероятно, нужно будет направить команду check на другой файл настроек, либо установив переменную среды DJANGO_SETTINGS_MODULE, либо передав параметр --settings:

python manage.py check --deploy --settings=production_settings

Или вы можете запустить его непосредственно на развертывании производства или этапа тестирования для проверки того, что используются правильные настройки (исключая --settings). Вы даже можете сделать его частью вашей интеграционной системы тестирования.

compilemessages

django-admin compilemessages

Компилирует файлы .po, созданные командой makemessages, в файлы .mo для использования с встроенной поддержкой gettext. См. Международная и локализация.

Используйте параметр --locale (или его сокращенную версию -l) для указания локалей для обработки. Если параметр не указан, обрабатываются все локали.

Используйте параметр --exclude (или его сокращенную версию -x) для указания локали(ей), которые нужно исключить из обработки. Если параметр не указан, никакие локали не исключаются.

Вы можете передать параметр --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.

dbshell

django-admin dbshell

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

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

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

Для указания базы данных, в которой нужно открыть оболочку, используется параметр --database.

diffsettings

django-admin diffsettings

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

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

Параметр --all может быть предоставлен для отображения всех настроек, даже если они имеют значение по умолчанию Django. Такие настройки предваряются "###".

dumpdata <app_label app_label app_label.Model ...>

django-admin dumpdata

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

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

Вывод dumpdata можно использовать в качестве входных данных для loaddata.

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

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

--format <fmt>

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

--indent <num>

По умолчанию dumpdata выводит все данные в одной строке. Это нелегко для чтения человеком, поэтому вы можете использовать опцию --indent для красивой печати вывода с указанным количеством отступов.

Опция --exclude может быть задана для предотвращения выгрузки конкретных приложений или моделей (указанных в форме app_label.ModelName). Если вы укажете имя модели в dumpdata, выгружаемый вывод будет ограничен этой моделью, а не всем приложением. Вы также можете комбинировать имена приложений и моделей.

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

--natural-foreign

При указании этой опции Django будет использовать метод модели natural_key() для сериализации любого внешнего ключа и связи «многие ко многим» до объектов типа, который определяет метод. Если вы выгружаете contrib.auth Permission объекты или contrib.contenttypes ContentType объекты, вам, вероятно, следует использовать этот флаг. См. документацию естественных ключей для получения более подробной информации об этом и следующей опции.

--natural-primary

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

--natural

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

--pks

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

--output

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

flush

django-admin flush

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

Опция --noinput может быть указана для подавления всех запросов к пользователю.

Опция --database может быть использована для указания базы данных для очистки.

--no-initial-data

Используйте --no-initial-data для избежания загрузки фикстуры initial_data.

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

loaddata <fixture fixture ...>

django-admin loaddata

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

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

--ignorenonexistent

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

--app

Опция --app может быть использована для указания отдельного приложения для поиска фикстур вместо поиска во всех приложениях.

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

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

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

Используйте опцию --all или -a для обновления файлов сообщений для всех доступных языков.

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

django-admin makemessages --all

--extension

Используйте опцию --extension или -e для указания списка расширений файлов для проверки (по умолчанию: ”.html”, ”.txt”).

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

django-admin makemessages --locale=de --extension xhtml

Разделяйте несколько расширений запятыми или используйте -e или –extension несколько раз:

django-admin makemessages --locale=de --extension=html,txt --extension xml

Используйте опцию --locale (или её короткую версию -l) для указания языковых локалей (locale) для обработки.

Используйте опцию --exclude (или её короткую версию -x) для указания локалей (locale), которые нужно исключить из обработки. Если не указано, локалей не будет исключено.

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

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 для изменения домена файлов сообщений. В настоящее время поддерживаются:

• django для всех файлов *.py, *.html и *.txt (по умолчанию)
• djangojs для файлов *.js

--symlinks

Используйте опцию --symlinks или -s для следования символичным ссылкам в каталоги при поиске новых строк для перевода.

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

django-admin makemessages --locale=de --symlinks

--ignore

Используйте опцию --ignore или -i для игнорирования файлов или каталогов, соответствующих заданному шаблону в стиле glob. Используйте несколько раз для игнорирования большего количества.

По умолчанию используются следующие шаблоны: 'CVS', '.*', '*~', '*.pyc'

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

django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html

--no-default-ignore

Используйте опцию --no-default-ignore для отключения значений по умолчанию для --ignore.

--no-wrap

Используйте опцию --no-wrap для отключения разбиения длинных строк сообщений на несколько строк в файлах языка.

--no-location

Используйте опцию --no-location для подавления записи комментариев ‘#: filename:line’ в файлах языка. Обратите внимание, что использование этой опции затрудняет понимание контекста каждого сообщения технически подкованным переводчикам.

--keep-pot

Используйте опцию --keep-pot для предотвращения удаления Django временных файлов .pot , которые он генерирует перед созданием файла .po. Это полезно для отладки ошибок, которые могут помешать созданию окончательных файлов языка.

makemigrations [<app_label>]

django-admin makemigrations

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

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

--empty

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

--dry-run

Опция --dry-run показывает, какие миграции будут созданы, не записывая фактически какие-либо файлы миграций на диск. Использование этой опции вместе с --verbosity 3 также покажет полные файлы миграций, которые будут записаны.

--merge

Опция --merge позволяет исправить конфликты миграций. Опция --noinput может быть предоставлена для подавления запросов пользователя во время слияния.

--name, -n

Опция --name позволяет задать миграции(ям) пользовательское имя вместо сгенерированного.

--exit, -e

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

migrate [<app_label> [<migrationname>]]

django-admin migrate

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

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

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

В отличие от syncdb, эта команда не предлагает создать суперпользователя, если он не существует (предполагается, что вы используете django.contrib.auth). Используйте createsuperuser для этого, если хотите.

Опция --database может быть использована для указания базы данных для миграции.

--fake

Опция --fake сообщает Django отметить миграции как применённые или отменённые, но без фактического выполнения SQL для изменения схемы вашей базы данных.

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

--fake-initial

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

runfcgi [options]

django-admin runfcgi

Запускает набор процессов FastCGI, подходящих для использования с любым веб-сервером, поддерживающим протокол FastCGI. Подробности см. в документации по развертыванию FastCGI. Требуется модуль Python FastCGI из flup.

Внутренне, это оборачивает объект приложения WSGI, указанный параметром WSGI_APPLICATION.

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

protocol

protocol=PROTOCOL

Используемый протокол. PROTOCOL может быть fcgi, scgi, ajp, и т.д. (по умолчанию fcgi).

host

host=HOSTNAME

Имя хоста для прослушивания.

port

port=PORTNUM

Порт для прослушивания.

socket

socket=FILE

Сокет UNIX для прослушивания.

method

method=IMPL

Возможные значения: prefork или threaded (по умолчанию prefork).

maxrequests

maxrequests=NUMBER

Количество запросов, обрабатываемых дочерним процессом, перед его завершением и созданием нового дочернего процесса (0 означает без ограничений).

maxspare

maxspare=NUMBER

Максимальное количество резервных процессов / потоков.

minspare

minspare=NUMBER

Минимальное количество резервных процессов / потоков.

maxchildren

maxchildren=NUMBER

Жёсткий лимит количества процессов / потоков.

daemonize

daemonize=BOOL

Отсоединиться от терминала.

pidfile

pidfile=FILE

Записать идентификатор запущенного процесса в файл FILE.

workdir

workdir=DIRECTORY

Изменить директорию на DIRECTORY при запуске в фоновом режиме.

debug

debug=BOOL

Установить в «истина», чтобы включить отладку flup.

outlog

outlog=FILE

Перенаправить стандартный вывод в файл FILE.

errlog

errlog=FILE

Перенаправить стандартный вывод ошибок в файл FILE.

umask

umask=UMASK

Маска, используемая при запуске в фоновом режиме. Значение интерпретируется как восьмеричное число (значение по умолчанию 0o22).

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

django-admin runfcgi socket=/tmp/fcgi.sock method=prefork daemonize=true \
    pidfile=/var/run/django-fcgi.pid

Запустить сервер FastCGI в фоновом режиме и записать PID запущенного процесса в файл.

runserver [port or address:port]

django-admin runserver

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

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

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

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

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

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

При запуске сервера и каждом изменении кода Python во время работы сервера, система проверит ваш весь проект Django на наличие распространённых ошибок (см. команду check). Если будут обнаружены ошибки, они будут выведены в стандартный вывод.

Вы можете запустить любое количество параллельных серверов, при условии, что они работают на разных портах. Просто выполните django-admin runserver более одного раза.

Обратите внимание, что по умолчанию IP-адрес 127.0.0.1 недоступен с других компьютеров в вашей сети. Чтобы сделать ваш сервер разработки доступным для других машин в сети, используйте собственный IP-адрес (например, 192.168.2.1) или 0.0.0.0 или :: (с поддержкой IPv6).

Вы можете указать IPv6-адрес в скобках (например, [200a::1]:8000). Это автоматически включит поддержку IPv6.

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

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

Если команда migrate не была ранее выполнена, таблица, хранящая историю миграций, создается при первом запуске runserver.

--noreload

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

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

django-admin runserver --noreload

--nothreading

Сервер разработки по умолчанию многопоточный. Используйте опцию --nothreading для отключения использования многопоточности на сервере разработки.

--ipv6, -6

Используйте параметр --ipv6 (или сокращённый -6) для использования IPv6 в сервере разработки. Это изменяет значение IP-адреса по умолчанию с 127.0.0.1 на ::1.

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

django-admin runserver --ipv6

Примеры использования различных портов и адресов

Порт 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).

shell

django-admin shell

Запускает интерактивный интерпретатор Python.

Django будет использовать IPython или bpython, если они установлены. Если у вас установлен расширенный интерпретатор, но вы хотите использовать обычный интерпретатор Python, используйте параметр --plain, например:

django-admin shell --plain

Если вы хотите указать IPython или bpython в качестве интерпретатора, если оба установлены, вы можете указать альтернативный интерфейс интерпретатора с параметрами -i или --interface, например:

IPython:

django-admin shell -i ipython
django-admin shell --interface ipython

bpython:

django-admin shell -i bpython
django-admin shell --interface bpython

Когда запускается обычный интерактивный интерпретатор Python (либо потому, что был указан --plain, либо из-за отсутствия других интерактивных интерфейсов), он читает скрипт, указанный переменной среды PYTHONSTARTUP и скрипт ~/.pythonrc.py. Если вы не хотите этого поведения, вы можете использовать параметр --no-startup, например:

django-admin shell --plain --no-startup

showmigrations [<app_label> [<app_label>]]

django-admin showmigrations

Отображает все миграции в проекте.

--list, -l

Параметр --list отображает все известные Django приложения, доступные миграции для каждого приложения и применены ли миграции (отмечены маркером [X] рядом с именем миграции).

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

--plan, -p

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

sql <app_label app_label ...>

django-admin sql

Выводит SQL-команды CREATE TABLE для заданного(ых) имени(й) приложения(ий).

Параметр --database может быть использован для указания базы данных, для которой нужно вывести SQL.

sqlall <app_label app_label ...>

django-admin sqlall

Выводит SQL-команды CREATE TABLE и initial-data для заданного(ых) имени(й) приложения(ий).

Обратитесь к описанию sqlcustom для получения объяснения способа указания начальных данных.

Параметр --database может быть использован для указания базы данных, для которой нужно вывести SQL.

sqlclear <app_label app_label ...>

django-admin sqlclear

Выводит SQL-команды DROP TABLE для заданного(ых) имени(й) приложения(ий).

Параметр --database может быть использован для указания базы данных, для которой нужно вывести SQL.

sqlcustom <app_label app_label ...>

django-admin sqlcustom

Выводит пользовательские SQL-команды для заданного(ых) имени(й) приложения(ий).

Для каждой модели в каждом указанном приложении эта команда ищет файл <app_label>/sql/<modelname>.sql, где <app_label> — имя заданного приложения, а <modelname> — имя модели в нижнем регистре. Например, если у вас есть приложение news, которое включает модель Story, sqlcustom попытается прочитать файл news/sql/story.sql и добавить его в вывод этой команды.

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

Обратите внимание, что порядок обработки SQL-файлов не определён.

Параметр --database может быть использован для указания базы данных, для которой нужно вывести SQL.

sqldropindexes <app_label app_label ...>

django-admin sqldropindexes

Выводит SQL-команды DROP INDEX для заданного(ых) имени(й) приложения(ий).

Параметр --database может быть использован для указания базы данных, для которой нужно вывести SQL.

sqlflush

django-admin sqlflush

Выводит SQL-команды, которые будут выполнены для команды flush.

Параметр --database может быть использован для указания базы данных, для которой нужно вывести SQL.

sqlindexes <app_label app_label ...>

django-admin sqlindexes

Выводит SQL-команды CREATE INDEX для заданного(ых) имени(й) приложения(ий).

Параметр --database может быть использован для указания базы данных, для которой нужно вывести SQL.

sqlmigrate <app_label> <migrationname>

django-admin sqlmigrate

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

Обратите внимание, что sqlmigrate не форматирует свой вывод.

Параметр --database может быть использован для указания базы данных, для которой нужно сгенерировать SQL.

--backwards

По умолчанию создаваемый SQL предназначен для выполнения миграции в прямом направлении. Передайте --backwards для генерации SQL для отмены миграции вместо этого.

sqlsequencereset <app_label app_label ...>

django-admin sqlsequencereset

Выводит SQL-команды для сброса последовательностей для заданного(ых) имени(й) приложения(ий).

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

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

Параметр --database может быть использован для указания базы данных, для которой нужно вывести SQL.

squashmigrations <app_label> <migration_name>

django-admin squashmigrations

Объединяет миграции для app_label до и включая migration_name вниз в меньшее количество миграций, если это возможно. Полученные объединённые миграции могут безопасно существовать вместе с не объединёнными. Для получения дополнительной информации, пожалуйста, ознакомьтесь с Объединение миграций.

--no-optimize

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

startapp <app_label> [destination]

django-admin startapp

Создаёт структуру директории приложения 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

Когда Django копирует файлы шаблона приложения, он также обрабатывает некоторые файлы с помощью движка шаблонов: файлы, расширения которых совпадают с параметром --extension (по умолчанию py) и файлы, имена которых передаются с параметром --name. Используемый template context:

• Любой параметр, переданный команде startapp (среди поддерживаемых параметров команды)
• app_name – имя приложения, переданное команде
• app_directory – полный путь к только что созданному приложению
• docs_version – версия документации: 'dev' или '1.x'

startproject <projectname> [destination]

django-admin startproject

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

По умолчанию новая директория содержит manage.py и пакет проекта (содержащий settings.py и другие файлы). Подробности см. в источнике шаблона.

Если указано только имя проекта, и директория проекта, и пакет проекта будут именоваться <projectname>, и директория проекта будет создана в текущей рабочей директории.

Если предоставлен необязательный параметр назначения, Django будет использовать эту существующую директорию как директорию проекта и создаст manage.py и пакет проекта внутри неё. Использование ‘.’ означает текущую рабочую директорию.

Например:

django-admin startproject myproject /Users/jezdez/Code/myproject_repo

Как и с командой startapp, параметр --template позволяет указать директорию, путь к файлу или URL-адрес пользовательского шаблона проекта. Подробности о поддерживаемых форматах шаблонов проекта см. в документации по команде startapp.

Например, это ищет шаблон проекта в данной директории при создании проекта myproject:

django-admin startproject --template=/Users/jezdez/Code/my_project_template myproject

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

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

django-admin startproject --template=https://github.com/githubuser/django-project-template/archive/master.zip myproject

Когда Django копирует файлы шаблона проекта, он также обрабатывает определённые файлы через движок шаблонов: файлы, расширения которых совпадают с параметром --extension (по умолчанию py) и файлы, имена которых передаются с параметром --name. Используемый template context:

• Любой параметр, переданный команде startproject (среди поддерживаемых параметров команды)
• project_name – имя проекта, переданное команде
• project_directory – полный путь к только что созданному проекту
• secret_key – случайный ключ для настройки SECRET_KEY
• docs_version – версия документации: 'dev' или '1.x'

Пожалуйста, также обратитесь к предупреждению об обработке, как упомянуто для startapp.

syncdb

django-admin syncdb

Псевдоним для migrate, за исключением того, что он также предлагает создать суперпользователя, если он не существует (предполагая, что вы используете django.contrib.auth).

test <app or test identifier>

django-admin test

Запускает тесты для всех установленных моделей. Дополнительную информацию см. в Тестирование в Django.

--failfast

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

--testrunner

Параметр --testrunner может использоваться для управления классом исполнителя тестов, который используется для выполнения тестов. Если это значение предоставлено, оно переопределяет значение, предоставленное настройкой TEST_RUNNER.

--liveserver

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

--keepdb

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

--reverse

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

--debug-sql

Параметр --debug-sql может быть использован для включения журналирования SQL для неудачных тестов. Если --verbosity имеет значение 2, то запросы в успешных тестах также выводятся.

testserver <fixture fixture ...>

django-admin testserver

Запускает сервер разработки Django (как и в runserver) с данными из заданного(ых) фикстуры(ы).

Например, эта команда:

django-admin testserver mydata.json

...выполнит следующие шаги:

1. Создаст тестовую базу данных, как описано в Тестовой базе данных.
2. Заполнит тестовую базу данных данными из заданных фикстур. (Подробнее о фикстурах см. документацию по loaddata выше.)
3. Запустит сервер разработки Django (как и в runserver), ориентированный на эту только что созданную тестовую базу данных вместо вашей рабочей базы данных.

Это полезно по многим причинам:

• При написании тестов модулей того, как ваши представления взаимодействуют с определенными данными фикстур, вы можете использовать testserver для взаимодействия с представлениями в веб-браузере вручную.
• Предположим, вы разрабатываете свое приложение Django и имеете «чистую» копию базы данных, с которой хотите взаимодействовать. Вы можете сохранить дамп своей базы данных в фикстуру (используя команду dumpdata, описанную выше), а затем использовать testserver для запуска своего веб-приложения с этими данными. С такой организацией у вас есть гибкость в изменении данных, зная, что любые изменения данных производятся только в тестовой базе данных.

Обратите внимание, что этот сервер не автоматически обнаруживает изменения в вашем исходном коде Python (в отличие от runserver). Однако он обнаруживает изменения в шаблонах.

--addrport [port number or ipaddr:port]

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

validate

django-admin validate

Проверяет все установленные модели (согласно настройке INSTALLED_APPS) и выводит ошибки проверки в стандартный вывод.

Команды, предоставляемые приложениями

Некоторые команды доступны только при установке приложения django.contrib, которое реализует их, и этом приложении enabled. Этот раздел описывает их, сгруппированные по приложениям.

django.contrib.auth

changepassword

django-admin changepassword

Эта команда доступна только если установлена система аутентификации Django система аутентификации (django.contrib.auth).

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

Используйте опцию --database для указания базы данных, в которой нужно искать пользователя. Если она не указана, Django будет использовать базу данных default.

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

django-admin changepassword ringo

createsuperuser

django-admin createsuperuser

Эта команда доступна только если установлена система аутентификации Django система аутентификации (django.contrib.auth).

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

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

--username

--email

Имя пользователя и адрес электронной почты для новой учётной записи можно указать, используя аргументы --username и --email в командной строке. Если ни один из них не указан, createsuperuser запросит их при интерактивном запуске.

Используйте опцию --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

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

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

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

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

--settings

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

django-admin migrate --settings=mysite.settings

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

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

--traceback

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

django-admin migrate --traceback

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

--verbosity

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

django-admin migrate --verbosity 2

Используйте --verbosity для указания объёма сообщений и отладочной информации, которые django-admin должен выводить в консоль.

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

--no-color

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

django-admin sqlall --no-color

По умолчанию django-admin отформатирует вывод, чтобы он был цветным. Например, ошибки будут выводиться в консоли красным цветом, а SQL-запросы будут иметь синтаксическую подсветку. Чтобы предотвратить это и получить вывод в формате простого текста, передайте опцию --no-color при запуске вашей команды.

Общие параметры

Следующие параметры не доступны для каждой команды, но они являются общими для ряда команд.

--database

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

Например, чтобы сохранить дамп данных из базы данных с псевдонимом master:

django-admin dumpdata --database=master

--exclude

Исключить конкретное приложение из приложений, содержимое которых выводится. Например, чтобы явно исключить приложение auth из вывода dumpdata, вы бы вызвали:

django-admin dumpdata --exclude=auth

Если вы хотите исключить несколько приложений, используйте несколько директив --exclude.

django-admin dumpdata --exclude=auth --exclude=contenttypes

--locale

Используйте параметр --locale или -l для указания языка для обработки. Если не указан, обрабатываются все языки.

--noinput

Используйте параметр --noinput для подавления всех запросов к пользователю, таких как подтверждения «Вы уверены?». Это полезно, если django-admin выполняется как автономный, автоматизированный скрипт.

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

Выделение синтаксиса

Команды 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 — незначительная ошибка.
• 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"

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

Поддержка цветного вывода утилит django-admin / manage.py в Windows, полагающейся на приложение ANSICON, была добавлена в Django 1.7.

Автозаполнение 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

список аргументов, принимаемых командой.

**options

именованные параметры, принимаемые в командной строке.

Примеры:

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)