django-admin и manage.py

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

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

Скрипт django-admin должен быть в вашем системном пути, если вы установили 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 ...]]

Использует фреймворк проверки системы система проверки для проверки всего проекта 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.

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

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

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

--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 более одного раза.

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

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

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

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

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

--noreload

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

--nothreading

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

--ipv6, -6

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

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

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

django-admin runserver

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

django-admin runserver 1.2.3.4:8000

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

django-admin runserver 7000

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

django-admin runserver 1.2.3.4:7000

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

django-admin runserver -6

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

django-admin runserver -6 7000

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

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

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

django-admin runserver localhost:8000

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

django-admin runserver -6 localhost:8000

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

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

sendtestemail

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

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

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

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

--managers

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

--admins

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

shell

django-admin shell

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

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

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

Приложения без миграций также отображаются, но под ними напечатано (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) или сжатому архиву (.tar.gz, .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 – имя приложения в формате 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

Сохраняет тестовую базу данных между запусками тестов. Это позволяет пропустить как создание, так и уничтожение, что значительно сокращает время выполнения тестов, особенно в большом наборе тестов. Если тестовая база данных не существует, она будет создана при первом запуске, а затем сохранена для каждого последующего запуска. Если настройка теста 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.

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

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

django.contrib.sessions

clearsessions

django-admin clearsessions

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

django.contrib.sitemaps

ping_google

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

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

django.contrib.staticfiles

collectstatic

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

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

findstatic

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

Обратитесь к документации 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 установлен в True.

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

django-admin migrate --skip-checks

Дополнительные удобства

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

DJANGO_COLORS

Команды 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"

Вы также можете настроить используемые цвета. 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, рассмотрите установку скрипта автодополнения Django bash, который находится в extras/django_bash_completion в дистрибутиве Django. Он позволяет автоматически дополнять django-admin и manage.py команды, поэтому вы можете, например…

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

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

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

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

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

name

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

*args

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

**options

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

Примеры:

from django.core import management
from django.core.management.commands import loaddata

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

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

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

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

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

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

Некоторые параметры команд имеют разные имена при использовании 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)