django-admin и manage.py

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

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

Скрипт django-admin должен быть в вашей системной переменной PATH, если вы установили Django через pip. Если его там нет, убедитесь, что у вас активирована виртуальная среда.

Как правило, при работе с одним проектом 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 ...]]

Использует фреймворк проверки системы system check framework для проверки всего проекта Django на распространённые проблемы.

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

django-admin check auth admin myapp

--tag TAGS, -t TAGS

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

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

--database DATABASE

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

django-admin check --database default --database other

По умолчанию эти проверки не выполняются.

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

--ignore PATTERN, -i PATTERN

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

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

django-admin compilemessages --ignore=cache --ignore=outdated/*/locale

createcachetable

django-admin createcachetable

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

--database DATABASE

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

--dry-run

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

dbshell

django-admin dbshell

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

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

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

--database DATABASE

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

-- ARGUMENTS

Любые аргументы после разделителя -- будут переданы подлежащему клиенту командной строки. Например, в PostgreSQL можно использовать флаг psql команды -c для прямого выполнения запроса SQL:

$ django-admin dbshell -- -c 'select current_user'
 current_user
--------------
 postgres
(1 row)

...\> django-admin dbshell -- -c 'select current_user'
 current_user
--------------
 postgres
(1 row)

В MySQL/MariaDB можно сделать это с помощью флага mysql команды -e:

$ django-admin dbshell -- -e "select user()"
+----------------------+
| user()               |
+----------------------+
| djangonaut@localhost |
+----------------------+

...\> django-admin dbshell -- -e "select user()"
+----------------------+
| user()               |
+----------------------+
| djangonaut@localhost |
+----------------------+

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 (по умолчанию), в терминале отображается полоса прогресса.

Сжатие фикстур

Файл вывода можно сжать с помощью одного из форматов bz2, gz, lzma, или xz, завершив имя файла соответствующим расширением. Например, чтобы вывести данные в сжатый JSON-файл:

django-admin dumpdata -o mydata.json.gz

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, lzma, или xz. Например:

django-admin loaddata mydata.json

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

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

Фикстуры, специфичные для базы данных

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

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

Загрузка фикстур из stdin

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

django-admin loaddata --format=json -

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

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

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

Подавляет все запросы пользователю. Пример запроса – о удалении устаревших типов контента.

--check

Заставляет migrate завершиться с ненулевым статусом при обнаружении не применённых миграций.

runserver

django-admin runserver [addrport]

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

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

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

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

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

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

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

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

Обратите внимание, что адрес по умолчанию 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 для сервера разработки. Это изменяет адрес по умолчанию с 127.0.0.1 на ::1.

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

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

django-admin runserver

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

django-admin runserver 1.2.3.4:8000

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

django-admin runserver 7000

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

django-admin runserver 1.2.3.4:7000

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

django-admin runserver -6

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

django-admin runserver -6 7000

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

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

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

django-admin runserver localhost:8000

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

django-admin runserver -6 localhost:8000

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

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

sendtestemail

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

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

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

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

--managers

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

--admins

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

shell

django-admin shell

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

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

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

IPython:

django-admin shell -i ipython

bpython:

django-admin shell -i bpython

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

django-admin shell -i python

--nostartup

Отключает чтение скрипта запуска для обычного интерпретатора Python. По умолчанию читается скрипт, указанный в переменной окружения 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] рядом с именем миграции). Для Django версии 2 и выше, также отображаются даты и время применения.

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

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

--plan, -p

Отображает план миграций, который Django будет использовать для применения миграций. Как и --list, применённые миграции помечаются символом [X]. Для Django версии 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) или сжатому архиву (.tar.gz, .tar.bz2, .tar.xz, .tar.lzma, .tgz, .tbz2, .txz, .tlz, .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 – имя приложения в формате с заглавными буквами
• 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

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

--reverse, -r

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

--debug-mode

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

--debug-sql, -d

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

--parallel [N]

DJANGO_TEST_PROCESSES

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

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

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

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

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

$ python -m pip install tblib

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

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

--tag TAGS

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

--exclude-tag EXCLUDE_TAGS

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

-k TEST_NAME_PATTERNS

Запускает тестовые методы и классы, соответствующие шаблонам имен тестов, аналогично unittest's -k option. Может быть указано несколько раз.

--pdb

Запускает отладчик pdb при каждой тестовой ошибке или сбое. Если он установлен, используется ipdb.

--buffer, -b

Отбрасывает вывод (stdout и stderr) для успешных тестов, аналогично unittest's --buffer option.

--no-faulthandler

Django автоматически вызывает faulthandler.enable() при запуске тестов, что позволяет ему выводить трассировку, если интерпретатор аварийно завершит работу. Передайте --no-faulthandler для отключения этого поведения.

--timing

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

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_SUPERUSER_PASSWORD

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

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

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

В неинтерактивном режиме поля USERNAME_FIELD и обязательные поля (перечисленные в REQUIRED_FIELDS) по умолчанию обращаются к переменным среды DJANGO_SUPERUSER_<uppercase_field_name>, если они не переопределены аргументом командной строки. Например, чтобы указать поле email, вы можете использовать переменную среды DJANGO_SUPERUSER_EMAIL.

--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 contenttypes (django.contrib.contenttypes) установлено.

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

--database DATABASE

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

--include-stale-apps

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

django.contrib.gis

ogrinspect

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

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

django.contrib.sessions

clearsessions

django-admin clearsessions

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

django.contrib.sitemaps

ping_google

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

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

django.contrib.staticfiles

collectstatic

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

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

findstatic

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

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

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

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

--pythonpath PYTHONPATH

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

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

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

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

--settings SETTINGS

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

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

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

django-admin migrate --settings=mysite.settings

--traceback

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

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

django-admin migrate --traceback

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

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

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

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

django-admin migrate --verbosity 2

--no-color

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

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

django-admin runserver --no-color

--force-color

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

--skip-checks

Пропускает выполнение системных проверок перед выполнением команды. Этот параметр доступен только в том случае, если атрибут команды requires_system_checks не является пустым списком или кортежем.

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

django-admin migrate --skip-checks

Дополнительные функции

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

DJANGO_COLORS

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

Поддержка Windows

В Windows 10 приложения Windows Terminal, VS Code и PowerShell (где включена обработка виртуального терминала) позволяют использовать цветной вывод и поддерживаются по умолчанию.

В Windows, в старой cmd.exe консоли не поддерживаются ANSI-escape-последовательности, поэтому по умолчанию цветной вывод отсутствует. В этом случае необходимо использовать одну из двух сторонних библиотек:

• Установите colorama, пакет Python, который преобразует ANSI-коды цвета в вызовы Windows API. Команды Django определят его наличие и будут использовать его для окрашивания вывода так же, как и на платформах на базе Unix. colorama можно установить через pip:

  ...\> py -m pip install colorama
  

• Установите ANSICON, стороннюю утилиту, которая позволяет cmd.exe обрабатывать ANSI-коды цвета. Команды Django определят его наличие и будут использовать его для окрашивания вывода так же, как и на платформах на базе Unix.

Другие современные терминальные среды на Windows, которые поддерживают цвета терминала, но которые не обнаруживаются Django как поддерживаемые, могут «подделать» установку ANSICON путём установки соответствующей переменной среды ANSICON="on".

Настройка цветов

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

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

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

export DJANGO_COLORS="light"

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

• error — серьёзная ошибка.
• notice — незначительная ошибка.
• success — успех.
• warning — предупреждение.
• sql_field — имя поля модели в SQL.
• sql_coltype — тип поля модели в SQL.
• sql_keyword — ключевое слово SQL.
• sql_table — имя модели в SQL.
• http_info — информативный ответ сервера HTTP (код 1XX).
• http_success — успешный ответ сервера HTTP (код 2XX).
• http_not_modified — ответ сервера HTTP «Не изменено» (код 304).
• http_redirect — ответ сервера HTTP «Переадресация» (код 3XX, кроме 304).
• http_not_found — ответ сервера HTTP «Не найдено» (код 404).
• http_bad_request — ответ сервера HTTP «Ошибка запроса» (код 4XX, кроме 404).
• http_server_error — ответ сервера HTTP «Ошибка сервера» (код 5XX).
• migrate_heading — заголовок в команде управления миграциями.
• migrate_label — имя миграции.

Каждой из этих ролей можно назначить определённый цвет переднего и заднего плана из следующего списка:

• black
• red
• green
• yellow
• blue
• magenta
• cyan
• white

Каждый из этих цветов затем можно изменить, используя следующие параметры отображения:

• bold
• underscore
• blink
• reverse
• conceal

Определение цвета следует одному из следующих шаблонов:

• role=fg
• role=fg/bg
• role=fg,option,option
• role=fg/bg,option,option

где role — имя допустимой роли цвета, fg — цвет переднего плана, bg — цвет фона, и каждый option — один из параметров модификации цвета. Несколько определений цвета разделяются точкой с запятой. Например:

export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"

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

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

export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"

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

Автодополнение Bash

Если вы используете оболочку Bash, рассмотрите возможность установки скрипта автодополнения Bash для Django, который находится в extras/django_bash_completion в дистрибутиве Django. Он позволяет автодополнять команды django-admin и manage.py, поэтому вы можете, например…

• Ввести django-admin.
• Нажать [TAB], чтобы увидеть все доступные варианты.
• Ввести sql, а затем [TAB], чтобы увидеть все доступные варианты, имена которых начинаются с sql.

См. Написание пользовательских команд django-admin для добавления настраиваемых действий.

Выполнение команд управления из вашего кода

django.core.management.call_command(name, *args, **options)

Для вызова команды управления из кода используйте call_command.

name

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

*args

список аргументов, принимаемых командой. Аргументы передаются в анализатор аргументов, поэтому вы можете использовать тот же стиль, что и в командной строке. Например, call_command('flush', '--verbosity=0').

**options

имена параметров, принимаемых в командной строке. Параметры передаются команде без запуска анализатора аргументов, что означает, что вам нужно передать правильный тип. Например, call_command('flush', verbosity=0) (ноль должен быть целым числом, а не строкой).

Примеры:

from django.core import management
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)