django-admin и manage.py

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

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

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

В целом, когда вы работаете над одним проектом 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 на наличие распространённых проблем.

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

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). Если какие-либо ошибки будут найдены, они будут выведены в стандартный вывод. Вы можете использовать опцию --skip-checks для пропуска выполнения проверок системы.

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

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

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

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

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

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

--noreload

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

--nothreading

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

--ipv6, -6

Использует IPv6 для сервера разработки. Это изменяет значение IP-адреса по умолчанию с 127.0.0.1 на ::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) которые должны быть обработаны движком шаблонов. По умолчанию пустой список.

--exclude DIRECTORIES, -x DIRECTORIES

Указывает каталоги в шаблоне приложения, которые должны быть исключены, в дополнение к .git и __pycache__. Если этот параметр не указан, будут исключены каталоги с именем __pycache__ или начинающиеся с ..

Используемый template context для всех соответствующих файлов:

• Любой параметр, переданный команде startapp (среди поддерживаемых параметров)
• app_name – имя приложения, переданное в команду
• app_directory – полный путь к вновь созданному приложению
• camel_case_app_name – имя приложения в формате camel case
• 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) которые должны быть обработаны движком шаблонов. По умолчанию пустой список.

--exclude DIRECTORIES, -x DIRECTORIES

Указывает каталоги в шаблоне проекта, которые должны быть исключены, в дополнение к .git и __pycache__. Если этот параметр не указан, будут исключены каталоги с именем __pycache__ или начинающиеся с ..

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

--shuffle [SEED]

Случайным образом изменяет порядок тестов перед их запуском. Это может помочь выявить тесты, которые не изолированы должным образом. Порядок тестов, сгенерированный с помощью этого параметра, является детерминированной функцией заданного целого числа (seed). Если seed не передан, seed выбирается случайным образом и выводится на консоль. Чтобы повторить определенный порядок тестов, передайте seed. Сгенерированные с помощью этого параметра порядки тестов сохраняют гарантии Django на порядок тестов. Они также сохраняют тесты, сгруппированные по классу тестового случая.

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

--reverse, -r

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

--debug-mode

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

--debug-sql, -d

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

--parallel [N]

DJANGO_TEST_PROCESSES

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

Использование --parallel без значения или со значением auto, запускает один процесс тестирования на ядро в соответствии с 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

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

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

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 и полный стек вызовов для любой другой исключительной ситуации.

Этот параметр игнорируется командой runserver.

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

django-admin migrate --traceback

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

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

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

Этот параметр игнорируется командой runserver.

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

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-коды цветов в вызовы API Windows. Команды 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, рассмотрите установку скрипта автодополнения 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)