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

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

Отображение вывода отладки¶

Use --verbosity, where it is supported, to specify the amount of notification and debug information that django-admin prints to the console.

check¶

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

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

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

django-admin check auth admin myapp

--tag TAGS, -t TAGS¶

Система проверки выполняет множество различных типов проверок, которые относятся к категории categorized with 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¶

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

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

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 сохраняется в файл, он может служить в качестве fixture для tests или в качестве initial data.

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

--all, -a¶

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

--format FORMAT¶

Определяет формат сериализации вывода. По умолчанию используется JSON. Поддерживаемые форматы перечислены в Форматы сериализации.

--indent INDENT¶

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

--exclude EXCLUDE, -e EXCLUDE¶

Prevents specific applications or models (specified in the form of app_label.ModelName) from being dumped. If you specify a model name, then only that model will be excluded, rather than the entire application. You can also mix application names and model names.

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

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

--database DATABASE¶

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

--natural-foreign¶

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

--natural-primary¶

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

--pks PRIMARY_KEYS¶

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

--output OUTPUT, -o OUTPUT¶

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

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

django-admin dumpdata -o mydata.json.gz

flush¶

django-admin flush¶

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

If you would rather start from an empty database and rerun all migrations, you should drop and recreate the database and then run migrate instead.

--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 является ее значением по умолчанию).

loaddata¶

django-admin loaddata fixture [fixture ...]¶

Searches for and loads the contents of the named fixture into the database.

--database DATABASE¶

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

--ignorenonexistent, -i¶

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

--app APP_LABEL¶

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

--format FORMAT¶

Указывает serialization format (например, json или xml) для фиксаторов read from stdin.

--exclude EXCLUDE, -e EXCLUDE¶

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

django-admin loaddata --format=json -

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

Эта команда не требует настроенных параметров. Однако, когда параметры не настроены, команда не может игнорировать каталоги 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 ...]]¶

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

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

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

--noinput, --no-input¶

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

--empty¶

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

--dry-run¶

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

--merge¶

Позволяет исправлять конфликты миграции.

--name NAME, -n NAME¶

Позволяет именовать сгенерированный переход(ы) вместо использования сгенерированного имени. Имя должно быть правильным Python identifier.

--no-header¶

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

--check¶

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

--scriptable¶

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

--update¶

Объединяет изменения модели в последнюю миграцию и оптимизирует результирующие операции.

migrate¶

django-admin migrate [app_label] [migration_name]¶

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

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

• Без споров: Все приложения выполнили все свои миграции.
• <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 выходить с ненулевым статусом при обнаружении непримененных миграций.

--prune¶

Удаляет несуществующие миграции из таблицы django_migrations. Это полезно, когда файлы миграции, замененные скомканной миграцией, были удалены. См. раздел Сжатие миграций для более подробной информации.

optimizemigration¶

django-admin optimizemigration app_label migration_name¶

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

--check¶

Makes optimizemigration exit with a non-zero status when a migration can be optimized.

runserver¶

django-admin runserver [addrport]¶

Starts a lightweight development web server on the local machine. By default, the server runs on port 8000 on the IP address 127.0.0.1. You can pass in an IP address and port number explicitly.

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

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

DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (And that’s how it’s gonna stay. We’re in the business of making web frameworks, not web servers, so improving this server to be able to handle a production environment is outside the scope of Django.)

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

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

When you start the server, and each time you change Python code while the server is running, the system check framework will check your entire Django project for some common errors (see the check command). If any errors are found, they will be printed to standard output. You can use the --skip-checks option to skip running system checks.

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

Note that the default IP address, 127.0.0.1, is not accessible from other machines on your network. To make your development server viewable to other machines on the network, use its own IP address (e.g. 192.168.2.1), 0 (shortcut for 0.0.0.0), 0.0.0.0, or :: (with IPv6 enabled).

Вы можете указать 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.

django-admin runserver

django-admin runserver 1.2.3.4:8000

django-admin runserver 7000

django-admin runserver 1.2.3.4:7000

django-admin runserver -6

django-admin runserver -6 7000

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

django-admin runserver localhost:8000

django-admin runserver -6 localhost:8000

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

--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 для заданного имени приложения в текущем каталоге или в заданном месте назначения.

По умолчанию the new directory содержит файл 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 app:

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/main.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 – имя приложения в формате верблюжьего регистра
• docs_version – версия документации: 'dev' или '1.x'
• django_version – версия Django, например, '2.0.3'

startproject¶

django-admin startproject name [directory]¶

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

По умолчанию the new directory содержит 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'

Please also see the rendering warning and trusted code warning as mentioned for startapp.

test¶

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

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

--failfast¶

Прекращает выполнение тестов и сообщает о неудаче сразу после того, как тест не прошел.

--testrunner TESTRUNNER¶

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

--noinput, --no-input¶

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

$ python -m pip install tblib

testserver¶

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

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

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

django-admin testserver mydata.json

…выполнить следующие действия:

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

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

• When you’re writing unit tests of how your views act with certain fixture data, you can use testserver to interact with the views in a web browser, manually.
• Let’s say you’re developing your Django application and have a «pristine» copy of a database that you’d like to interact with. You can dump your database to a fixture (using the dumpdata command, explained above), then use testserver to run your web application with that data. With this arrangement, you have the flexibility of messing up your data in any way, knowing that whatever data changes you’re making are only being made to a test database.

Обратите внимание, что этот сервер не автоматически определяет изменения в вашем исходном коде 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.auth¶

django-admin changepassword ringo

django.contrib.contenttypes¶

django.contrib.gis¶

django.contrib.sessions¶

django.contrib.sitemaps¶

django.contrib.staticfiles¶

Синтаксическая раскраска¶

DJANGO_COLORS¶

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

export DJANGO_COLORS="light"

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

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

Завершение Bash¶

If you use the Bash shell, consider installing the Django bash completion script, which lives in extras/django_bash_completion in the Django source distribution. It enables tab-completion of django-admin and manage.py commands, so you can, for instance…

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

О том, как добавить настраиваемые действия, смотрите How to create custom django-admin commands.

Черное форматирование¶

Файлы Python, созданные командами startproject, startapp, optimizemigration, makemigrations и squashmigrations, форматируются с помощью команды black, если она присутствует на вашем PATH.

Если у вас глобально установлен black, но вы не хотите, чтобы он использовался для текущего проекта, вы можете установить PATH явно:

PATH=path/to/venv/bin django-admin makemigrations

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

django-admin inspectdb | black -