django-admin и manage.py

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

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

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

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

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

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

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

$ django-admin <command> [options]
$ manage.py <command> [options]
$ python -m django <command> [options]

...\> django-admin <command> [options]
...\> manage.py <command> [options]
...\> py -m django <command> [options]

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

Получение помощи во время выполнения

django-admin help

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

Запустите django-admin help --commands для отображения списка всех доступных команд.

Запустите django-admin help <command> для отображения описания данной команды и списка доступных опций.

Имена приложений

Многие команды принимают список «имен приложений». «Имя приложения» — это базовое имя пакета, содержащего ваши модели. Например, если ваша INSTALLED_APPS содержит строку 'mysite.blog', то имя приложения — blog.

Определение версии

django-admin version

Запустите django-admin version для отображения текущей версии Django.

Вывод следует схеме, описанной в PEP 440:

1.4.dev17026
1.4a1
1.4

Отображение отладочного вывода

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

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

check

django-admin check [app_label [app_label ...]]

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

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

django-admin check auth admin myapp

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

--tag TAGS, -t TAGS

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

django-admin check --tag models --tag compatibility

--list-tags

Отображает все доступные метки.

--deploy

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

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

django-admin check --deploy --settings=production_settings

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

--fail-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}

Указывает уровень сообщения, который заставит команду завершиться с ненулевым кодом состояния. По умолчанию — ERROR.

compilemessages

django-admin compilemessages

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

--locale LOCALE, -l LOCALE

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

--exclude EXCLUDE, -x EXCLUDE

Указывает языковые настройки, которые нужно исключить из обработки. Если не указано, не исключается ни одна языковая настройка.

--use-fuzzy, -f

Включает неточные переводы в скомпилированные файлы.

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

django-admin compilemessages --locale=pt_BR
django-admin compilemessages --locale=pt_BR --locale=fr -f
django-admin compilemessages -l pt_BR
django-admin compilemessages -l pt_BR -l fr --use-fuzzy
django-admin compilemessages --exclude=pt_BR
django-admin compilemessages --exclude=pt_BR --exclude=fr
django-admin compilemessages -x pt_BR
django-admin compilemessages -x pt_BR -x fr

createcachetable

django-admin createcachetable

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

--database DATABASE

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

--dry-run

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

dbshell

django-admin dbshell

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

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

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

--database DATABASE

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

diffsettings

django-admin diffsettings

Отображает различия между текущим файлом настроек и файлом настроек по умолчанию Django (или другим файлом настроек, указанным в --default).

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

--all

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

--default MODULE

Модуль настроек для сравнения с текущими настройками. Оставьте пустым, чтобы сравнить с настройками по умолчанию Django.

--output {hash,unified}

Указывает формат вывода. Доступные значения — hash и unified. hash — это режим по умолчанию, отображающий вывод, описанный выше. unified отображает вывод, похожий на diff -u. Настройки по умолчанию предваряются знаком минус, за которым следует изменённая настройка, предваряемая знаком плюс.

dumpdata

django-admin dumpdata [app_label[.ModelName] [app_label[.ModelName] ...]]

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

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

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

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

--all, -a

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

--format FORMAT

Указывает формат сериализации вывода. По умолчанию JSON. Поддерживаемые форматы перечислены в форматах сериализации.

--indent INDENT

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

--exclude EXCLUDE, -e EXCLUDE

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

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

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

--database DATABASE

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

--natural-foreign

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

--natural-primary

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

--pks PRIMARY_KEYS

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

--output OUTPUT, -o OUTPUT

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

Когда этот параметр установлен, и --verbosity больше 0 (по умолчанию), в терминале отображается индикатор выполнения.

flush

django-admin flush

Удаляет все данные из базы данных и повторно выполняет любые обработчики пост-синхронизации. Таблица примененных миграций не очищается.

Если вы предпочитаете начать с пустой базы данных и повторно выполнить все миграции, вам следует удалить и пересоздать базу данных, а затем выполнить migrate вместо этого.

--noinput, --no-input

Отключает все запросы к пользователю.

--database DATABASE

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

inspectdb

django-admin inspectdb [table [table ...]]

Проверяет таблицы базы данных в базе данных, на которую указывает параметр NAME, и выводит модуль модели Django (файл models.py ) в стандартный вывод.

Вы можете выбрать таблицы или представления для проверки, передав их имена в качестве аргументов. Если аргументы не предоставлены, модели создаются только для представлений, если используется параметр --include-views. Модели для таблиц разбиений создаются на PostgreSQL, если используется параметр --include-partitions.

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

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

• Если inspectdb не может сопоставить тип столбца с типом поля модели, он будет использовать TextField и вставит Python-комментарий 'This field type is a guess.' рядом с полем в сгенерированной модели. Распознаваемые поля могут зависеть от приложений, перечисленных в INSTALLED_APPS. Например, django.contrib.postgres добавляет распознавание нескольких типов полей, специфичных для PostgreSQL.
• Если имя столбца базы данных является зарезервированным словом Python (таким как 'pass', 'class' или 'for'), inspectdb добавит '_field' к имени атрибута. Например, если таблица имеет столбец 'for', сгенерированная модель будет иметь поле 'for_field', с атрибутом db_column , установленным в значение 'for'. inspectdb вставит Python-комментарий 'Field renamed because it was a Python reserved word.' рядом с полем.

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

Django не создает значения по умолчанию базы данных, когда на поле модели указано default. Аналогично, значения по умолчанию базы данных не переводятся в значения по умолчанию поля модели или не обнаруживаются inspectdb.

По умолчанию inspectdb создаёт несвязанные модели. То есть, managed = False в классе Meta модели сообщает Django, что он не должен управлять созданием, изменением и удалением каждой таблицы. Если вы хотите, чтобы Django управлял жизненным циклом таблицы, вам необходимо изменить параметр managed на True (или просто удалить его, поскольку True является его значением по умолчанию).

Примечания к базе данных

Oracle

• Модели создаются для материализованных представлений, если используется --include-views.

PostgreSQL

• Модели создаются для внешних таблиц.
• Модели создаются для материализованных представлений, если используется --include-views.
• Модели создаются для таблиц разбиений, если используется --include-partitions.

--database DATABASE

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

--include-partitions

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

Реализована только поддержка PostgreSQL.

--include-views

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

loaddata

django-admin loaddata fixture [fixture ...]

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

--database DATABASE

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

--ignorenonexistent, -i

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

--app APP_LABEL

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

--format FORMAT

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

--exclude EXCLUDE, -e EXCLUDE

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

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

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

Django будет искать файлы-образцы в трех местах:

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

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

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

django-admin loaddata mydata.json

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

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

django-admin loaddata mydata

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

Имена файлов-образцов могут включать компоненты каталога. Эти каталоги будут включены в путь поиска. Например:

django-admin loaddata foo/bar/mydata.json

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

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

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

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

post_save.connect(my_handler, sender=MyModel)

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

from functools import wraps

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

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

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

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

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

Сжатые файлы-образцы

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

django-admin loaddata mydata.json

будет искать любой из mydata.json, mydata.json.zip, mydata.json.gz или mydata.json.bz2. Используется первый файл в сжатом архиве zip.

Обратите внимание, что если обнаружены два файла-образца с одинаковым именем, но разными типами (например, если mydata.json и mydata.xml.gz были найдены в одном каталоге файлов-образцов), установка файла-образца будет прервана, и любые данные, установленные в вызове loaddata, будут удалены из базы данных.

Файлы-образцы для конкретной базы данных

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

Например, если в настройке DATABASES определена база данных «master», назовите файл-образец mydata.master.json или mydata.master.json.gz, и файл-образец будет загружен только при указании загрузки данных в базу данных master.

Загрузка файлов-образцов из стандартного ввода

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

django-admin loaddata --format=json -

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

Загрузка из стандартного ввода полезна при использовании перенаправления стандартного ввода и вывода. Например:

django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -

makemessages

django-admin makemessages

Обрабатывает всю древовидную структуру исходного кода текущего каталога и извлекает все строки, помеченные для перевода. Создает (или обновляет) файл сообщений в каталоге conf/locale (в дереве Django) или каталоге locale (для проекта и приложения). После внесения изменений в файлы сообщений необходимо скомпилировать их с помощью compilemessages для использования с встроенной поддержкой gettext. Подробности см. в документации по i18n.

Эта команда не требует настроенных настроек. Однако, если настройки не настроенны, команда не может игнорировать каталоги MEDIA_ROOT и STATIC_ROOT или включать LOCALE_PATHS.

--all, -a

Обновляет файлы сообщений для всех доступных языков.

--extension EXTENSIONS, -e EXTENSIONS

Указывает список расширений файлов для проверки (по умолчанию: html, txt, py или js если --domain равно js).

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

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

Укажите несколько расширений через запятые или используйте -e или --extension несколько раз:

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

--locale LOCALE, -l LOCALE

Указывает локаль(и) для обработки.

--exclude EXCLUDE, -x EXCLUDE

Указывает локаль(и) для исключения из обработки. Если не указано, локаль не исключается.

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

django-admin makemessages --locale=pt_BR
django-admin makemessages --locale=pt_BR --locale=fr
django-admin makemessages -l pt_BR
django-admin makemessages -l pt_BR -l fr
django-admin makemessages --exclude=pt_BR
django-admin makemessages --exclude=pt_BR --exclude=fr
django-admin makemessages -x pt_BR
django-admin makemessages -x pt_BR -x fr

--domain DOMAIN, -d DOMAIN

Указывает домен файлов сообщений. Поддерживаемые варианты:

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

--symlinks, -s

Следует за символическими ссылками в каталоги при поиске новых строк перевода.

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

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

--ignore PATTERN, -i PATTERN

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

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

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

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

--no-default-ignore

Отключает значения по умолчанию --ignore.

--no-wrap

Отключает разбиение длинных строк сообщений на несколько строк в языковых файлах.

--no-location

Запрещает запись комментариев «#: filename:line» в языковых файлах. Использование этого параметра затрудняет технически подкованным переводчикам понимание контекста каждого сообщения.

--add-location [{full,file,never}]

Управляет комментариями #: filename:line в языковых файлах. Если параметр:

• full (по умолчанию, если не указано): строки включают имя файла и номер строки.
• file: номер строки опускается.
• never: строки подавляются (так же, как --no-location).

Требуется gettext 0.19 или новее.

--keep-pot

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

makemigrations

django-admin makemigrations [app_label [app_label ...]]

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

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

Чтобы добавить миграции в приложение, у которого нет каталога migrations, запустите makemigrations с app_label приложения.

--noinput, --no-input

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

--empty

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

--dry-run

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

--merge

Включает исправление конфликтов миграций.

--name NAME, -n NAME

Разрешает присваивать имя сгенерированным миграциям вместо использования сгенерированного имени. Имя должно быть допустимым Python идентификатором.

--no-header

Генерирует файлы миграций без заголовка версии Django и отметки времени.

--check

Приводит makemigrations к выходу с ненулевым статусом при обнаружении изменений модели без миграций.

migrate

django-admin migrate [app_label] [migration_name]

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

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

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

--database DATABASE

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

--fake

Помечает миграции до целевой миграции (следуя правилам выше) как применённые, но без фактического выполнения SQL для изменения схемы вашей базы данных.

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

--fake-initial

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

--plan

Отображает операции миграции, которые будут выполнены для данной migrate команды.

--run-syncdb

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

--noinput, --no-input

Отключает все запросы пользователю. Пример запроса — об удалении устаревших типов содержимого.

runserver

django-admin runserver [addrport]

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

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

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

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

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

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

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

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

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

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

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

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

Журналирование каждого запроса и ответа сервера отправляется в логгер django.server.

--noreload

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

--nothreading

Отключает использование потоков в сервере разработки. По умолчанию сервер многопоточный.

--ipv6, -6

Использует IPv6 для сервера разработки. Это изменяет адрес IP по умолчанию с 127.0.0.1 на --ipv6, -6.

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

Порт 8000 по адресу 127.0.0.1:

django-admin runserver

Порт 8000 по адресу 1.2.3.4:

django-admin runserver 1.2.3.4:8000

Порт 7000 по адресу 127.0.0.1:

django-admin runserver 7000

Порт 7000 по адресу 1.2.3.4:

django-admin runserver 1.2.3.4:7000

Порт 8000 по IPv6-адресу ::1:

django-admin runserver -6

Порт 7000 по IPv6-адресу ::1:

django-admin runserver -6 7000

Порт 7000 по IPv6-адресу 2001:0db8:1234:5678::9:

django-admin runserver [2001:0db8:1234:5678::9]:7000

Порт 8000 по IPv4-адресу хоста localhost:

django-admin runserver localhost:8000

Порт 8000 по IPv6-адресу хоста localhost:

django-admin runserver -6 localhost:8000

Отправка статических файлов с сервером разработки

По умолчанию сервер разработки не отправляет какие-либо статические файлы для вашего сайта (такие как файлы CSS, изображения, элементы в MEDIA_URL и т. д.). Если вы хотите настроить Django на отправку статических медиа, прочитайте Управление статическими файлами (например, изображениями, JavaScript, CSS).

sendtestemail

django-admin sendtestemail [email [email ...]]

Отправляет тестовое электронное письмо (для подтверждения работы отправки электронных писем через Django) получателю(ям), указанному. Например:

django-admin sendtestemail foo@example.com bar@example.com

Есть несколько вариантов, и вы можете использовать любое их сочетание:

--managers

Отправляет электронные письма, указанные в MANAGERS, с использованием mail_managers().

--admins

Отправляет электронные письма, указанные в ADMINS, с использованием mail_admins().

shell

django-admin shell

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

--interface {ipython,bpython,python}, -i {ipython,bpython,python}

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

IPython:

django-admin shell -i ipython

bpython:

django-admin shell -i bpython

Если у вас установлена «оболочка» rich, но вы хотите принудительно использовать обычный интерпретатор Python, используйте python как имя интерфейса, например:

django-admin shell -i python

--nostartup

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

--command COMMAND, -c COMMAND

Позволяет передать команду как строку для её выполнения как Django, например:

django-admin shell --command="import django; print(django.__version__)"

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

$ django-admin shell <<EOF
> import django
> print(django.__version__)
> EOF

В Windows REPL выводится из-за ограничений реализации select.select() на этой платформе.

showmigrations

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

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

--list, -l

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

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

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

--plan, -p

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

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

--database DATABASE

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

sqlflush

django-admin sqlflush

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

--database DATABASE

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

sqlmigrate

django-admin sqlmigrate app_label migration_name

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

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

--backwards

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

--database DATABASE

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

sqlsequencereset

django-admin sqlsequencereset app_label [app_label ...]

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

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

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

--database DATABASE

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

squashmigrations

django-admin squashmigrations app_label [start_migration_name] migration_name

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

При указании start_migration_name, Django будет включать только миграции, начиная с этой миграции и включая её. Это помогает уменьшить ограничения сжатия миграций RunPython и django.db.migrations.operations.RunSQL.

--no-optimize

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

--noinput, --no-input

Отключает все запросы пользователю.

--squashed-name SQUASHED_NAME

Устанавливает имя сжатой миграции. Если не указано, имя основано на первой и последней миграции с _squashed_ между ними.

--no-header

Генерирует файл сжатой миграции без заголовка версии Django и отметки времени.

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'
• django_version – версия Django, например '2.0.3'

startproject

django-admin startproject name [directory]

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

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

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

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

Например:

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

--template TEMPLATE

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

--extension EXTENSIONS, -e EXTENSIONS

Указывает расширения файлов в шаблоне проекта, которые должны быть обработаны движком шаблонов. По умолчанию py.

--name FILES, -n FILES

Указывает файлы в шаблоне проекта (кроме тех, которые соответствуют --extension), которые должны быть обработаны движком шаблонов. По умолчанию пустой список.

Используемый template context:

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

Также обратите внимание на предупреждение о рендеринге, упомянутое для startapp.

test

django-admin test [test_label [test_label ...]]

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

--failfast

Прекращает выполнение тестов и сразу же сообщает об ошибке после обнаружения ошибки в тесте.

--testrunner TESTRUNNER

Управляет классом исполнителя тестов, который используется для выполнения тестов. Это значение переопределяет значение, предоставленное настройкой TEST_RUNNER.

--noinput, --no-input

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

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

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

--keepdb, -k

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

--reverse, -r

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

DEBUG

Устанавливает настройку DEBUG в True перед запуском тестов. Это может помочь в устранении неполадок в тестах.

--debug-sql, -d

Включает логирование SQL для не пройденных тестов. Если --verbosity равно 2, запросы в пройденных тестах также выводятся.

--parallel [N]

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

По умолчанию --parallel запускает один процесс на ядро в соответствии с multiprocessing.cpu_count(). Количество процессов можно настроить, либо указав его в качестве значения параметра, например, --parallel=4, либо установив переменную окружения DJANGO_TEST_PROCESSES.

Django распределяет тестовые случаи — подклассы unittest.TestCase — по подпроцессам. Если количество тестовых случаев меньше, чем количество настроенных процессов, Django уменьшит количество процессов соответственно.

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

Для корректного отображения отладочных сообщений требуется пакет сторонних разработчиков tblib:

$ pip install tblib

Эта функция недоступна в Windows. Она также не работает с бэкэндом базы данных Oracle.

Если вы хотите использовать pdb при отладке тестов, необходимо отключить параллельное выполнение (--parallel=1). В противном случае вы увидите что-то вроде bdb.BdbQuit.

--tag TAGS

Запускает только тесты отмеченные указанными тегами. Можно указывать несколько раз и комбинировать с test --exclude-tag.

--exclude-tag EXCLUDE_TAGS

Исключает тесты отмеченные указанными тегами. Можно указывать несколько раз и комбинировать с test --tag.

testserver

django-admin testserver [fixture [fixture ...]]

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

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

django-admin testserver mydata.json

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

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

Это полезно в нескольких случаях:

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

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

--addrport ADDRPORT

Устанавливает другой порт или IP-адрес и порт по умолчанию 127.0.0.1:8000. Это значение имеет точно такой же формат и выполняет точно такую же функцию, как аргумент команды runserver.

Примеры:

Для запуска тестового сервера на порту 7000 с fixture1 и fixture2:

django-admin testserver --addrport 7000 fixture1 fixture2
django-admin testserver fixture1 fixture2 --addrport 7000

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

Для запуска на 1.2.3.4:7000 с test фикстурой:

django-admin testserver --addrport 1.2.3.4:7000 test

--noinput, --no-input

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

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

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

django.contrib.auth

changepassword

django-admin changepassword [<username>]

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

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

--database DATABASE

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

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

django-admin changepassword ringo

createsuperuser

django-admin createsuperuser

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

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

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

--noinput, --no-input

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

--username USERNAME

--email EMAIL

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

--database DATABASE

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

Вы можете расширить менеджер управления и переопределить get_input_data(), если хотите настроить ввод и проверку данных. Обратитесь к исходному коду для получения подробностей о текущей реализации и параметрах метода. Например, это может быть полезно, если у вас есть ForeignKey в REQUIRED_FIELDS и вы хотите создать экземпляр вместо ввода первичного ключа существующего экземпляра.

django.contrib.contenttypes

remove_stale_contenttypes

django-admin remove_stale_contenttypes

Эта команда доступна только при установке приложения Django для типов содержимого (приложение типов содержимого) (django.contrib.contenttypes).

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

--database DATABASE

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

django.contrib.gis

ogrinspect

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

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

django.contrib.sessions

clearsessions

django-admin clearsessions

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

django.contrib.sitemaps

ping_google

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

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

django.contrib.staticfiles

collectstatic

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

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

findstatic

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

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

Основные параметры

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

--pythonpath PYTHONPATH

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

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

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

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

--settings SETTINGS

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

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

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

django-admin migrate --settings=mysite.settings

--traceback

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

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

django-admin migrate --traceback

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

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

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

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

django-admin migrate --verbosity 2

--no-color

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

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

django-admin runserver --no-color

--force-color

Принудительно включает цветной вывод команды, если он был бы отключен, как обсуждалось в Синтаксическое выделение. Например, вы можете перенаправить цветной вывод в другую команду.

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

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

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

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

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

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

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

export DJANGO_COLORS="light"

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

• error — серьезная ошибка.
• notice — незначительная ошибка.
• success — успех.
• warning — предупреждение.
• sql_field — имя поля модели в SQL.
• sql_coltype — тип поля модели в SQL.
• sql_keyword — ключевое слово SQL.
• sql_table — имя модели в SQL.
• http_info — информационный ответ сервера HTTP 1XX.
• http_success — успешный ответ сервера HTTP 2XX.
• http_not_modified — ответ сервера HTTP 304 Not Modified.
• http_redirect — ответ сервера HTTP 3XX Redirect, кроме 304.
• http_not_found — ответ сервера HTTP 404 Not Found.
• http_bad_request — ответ сервера HTTP 4XX Bad Request, кроме 404.
• http_server_error — ответ сервера HTTP 5XX Server Error.
• 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
from django.core.management.commands import loaddata

management.call_command('flush', verbosity=0, interactive=False)
management.call_command('loaddata', 'test_data', verbosity=0)
management.call_command(loaddata.Command(), 'test_data', verbosity=0)

Обратите внимание, что параметры команды, которые не принимают аргументы, передаются в качестве ключевых слов с True или False, как вы можете видеть с параметром interactive выше.

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

# Similar to the command line
management.call_command('dumpdata', '--natural-foreign')

# Named argument similar to the command line minus the initial dashes and
# with internal dashes replaced by underscores
management.call_command('dumpdata', natural_foreign=True)

# `use_natural_foreign_keys` is the option destination variable
management.call_command('dumpdata', use_natural_foreign_keys=True)

У некоторых параметров команд есть разные имена, когда вместо call_command() используется django-admin или manage.py. Например, django-admin createsuperuser --no-input переводится в call_command('createsuperuser', interactive=False). Чтобы узнать, какое имя ключевого аргумента использовать для call_command(), проверьте исходный код команды для аргумента dest , переданного в parser.add_argument().

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

management.call_command('dumpdata', exclude=['contenttypes', 'auth'])

Возвращаемое значение функции call_command() такое же, как возвращаемое значение метода handle() команды.

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

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

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