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

django-admin help¶

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

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

Выполните django-admin help <command>, чтобы вывести описание заданной команды и список ее доступных опций.

Названия приложений¶

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

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

django-admin version¶

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

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

1.4.dev17026
1.4a1
1.4

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

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

check¶

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

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

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

django-admin check auth admin myapp

--tag TAGS, -t TAGS¶

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

Предотвращает сброс определенных приложений или моделей (указанных в форме 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 keys.

--natural-primary¶

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

--pks PRIMARY_KEYS¶

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

--output OUTPUT, -o OUTPUT¶

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

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

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

loaddata¶

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

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

--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 или новее.

--no-obsolete¶

Удаляет устаревшие строки сообщений из файлов .po.

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

--scriptable¶

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

--update¶

Слияние изменений модели в последнюю миграцию и оптимизация результирующих операций.

Обновленная миграция будет иметь сгенерированное имя. Чтобы сохранить прежнее имя, задайте его с помощью --name.

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¶

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

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

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

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

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

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

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

Запись каждого запроса и ответа сервера отправляется в логгер django.server.

--noreload¶

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

--nothreading¶

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

--ipv6, -6¶

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

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 оно будет искать шаблон приложения в указанном каталоге:

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'

Смотрите также rendering warning и trusted code warning, как указано для 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), направленный на эту недавно созданную тестовую базу данных вместо вашей производственной базы данных.

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

• Когда вы пишете unit tests о том, как ваши представления действуют с определенными данными приспособления, вы можете использовать testserver для взаимодействия с представлениями в веб-браузере, вручную.
• Допустим, вы разрабатываете Django-приложение и у вас есть «чистая» копия базы данных, с которой вы хотели бы взаимодействовать. Вы можете сделать дамп базы данных в файл fixture (с помощью команды 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.auth¶

django-admin changepassword ringo

django.contrib.contenttypes¶

django.contrib.gis¶

django.contrib.sessions¶

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¶

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

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

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

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

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

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

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

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

django-admin inspectdb | black -