3.2
5.0
6.1
Версия документации: 3.1

django-admin и manage.py¶

django-admin – это консольный инструмент Django. Этот раздел описывает его возможности.

Также для каждого проекта автоматически создается manage.py. manage.py – это простой интерфейс для django-admin, но есть ряд отличий:

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

При работе с одним проектом Django удобнее использоваться manage.py, чем django-admin. Если вам необходимо переключаться между различными фалами настройки, используйте django-admin с переменной окружения DJANGO_SETTINGS_MODULE или опцией :djadminopt:`--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¶

django-admin version¶

Выполните django-admin version, чтобы получить текущую версию Django.

The output follows the schema described in PEP 440:

4.dev17026
4a1
4

Вывод отладочной информации¶

Use --verbosity to specify the amount of notification and debug information that django-admin prints to the console.

Доступные команды¶

`black`¶

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

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

By default, all apps will be checked. You can check a subset of apps by providing a list of app labels as arguments:

django-admin check auth admin myapp

--tag TAGS, -t TAGS¶

The system check framework performs many different types of checks that are categorized with tags. You can use these tags to restrict the checks performed to just those in a particular category. For example, to perform only models and compatibility checks, run:

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

--database DATABASE¶

New in Django 3.1.

Specifies the database to run checks requiring database access:

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

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

--list-tags¶

Выводит список всех доступных тегов.

--deploy¶

Опция --deploy выполняет дополнительные проверки, которые уместны только для настроек сервера, а не окружения для разработки.

You can use this option in your local development environment, but since your local development settings module may not have many of your production settings, you will probably want to point the check command at a different settings module, either by setting the DJANGO_SETTINGS_MODULE environment variable, or by passing the --settings option:

django-admin check --deploy --settings=production_settings

Вы можете использовать эту опцию на «боевом» или тестовом сервере (без --settings). Вы даже можете сделать проверку частью тестов.

--fail-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}¶

Указывает уровень сообщения, при котором команда завершится с ненулевым статусом. По умолчанию установлено ОШИБКА.

compilemessages¶

django-admin compilemessages¶

Компилирует .po файлы, созданные командой makemessages, в файлы .mo, которые используются gettext для локализации проекта. Смотрите Интернационализация и локализация.

--locale LOCALE, -l LOCALE¶

Опция --locale или -l позволяет указать локаль, которая будет использоваться при выполнении команды.

--exclude EXCLUDE, -x EXCLUDE¶

Опция :djadminopt:`--exclude` (или короткий вариант -x) позволяет исключить локали из обработки. Если не указана, ни одна локаль не будет исключена.

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

New in Django 3.0.

Опция --ignore или -i позволяет игнорировать файлы или каталоги, которые соответствуют указанному шаблону в стиле glob. Можно указать несколько раз.

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

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

createcachetable¶

django-admin createcachetable¶

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

--database DATABASE¶

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

--dry-run¶

Опция :djadminopt:`--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¶

New in Django 3.1.

Любые аргументы после разделителя -- будут переданы базовому клиенту командной строки. Например, в PostgreSQL вы можете использовать флаг -c команды psql для прямого выполнения необработанного 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 это можно сделать с помощью флага -e команды mysql:

/ 

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

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

Примечание

Имейте в виду, что не все параметры, установленные в части OPTIONS конфигурации вашей базы данных в DATABASES, передаются клиенту командной строки, например. 'изоляционный_уровень'.

diffsettings¶

django-admin diffsettings¶

Показывает разницу между текущими настройками и настройками Django по умолчанию.

Настройки, которые не указаны в настройках по умолчанию, выводятся с "###" в конце. Например, в настройках по умолчанию не указан ROOT_URLCONF, и в выводе diffsettings, к ROOT_URLCONF будет добавлен "###" в конце.

--all¶

Опция :djadminopt:`--all` позволяет вывести все настройки, даже если они не отличаются от настроек по умолчанию. Такие настройки выводятся с префиксом "###".

--default MODULE¶

Показывает разницу между текущими настройками и настройками Django по умолчанию.

--output {hash,unified}¶

Определяет выходной формат. Доступные значения: hash и unified. хеш — это режим по умолчанию, в котором отображаются выходные данные, описанные выше. unified отображает вывод, аналогичный diff -u. Настройки по умолчанию имеют префикс со знаком минус, за которым следуют измененные настройки со знаком плюс.

`magenta`¶

django-admin dumpdata [app_label[.ModelName] [app_label[.ModelName] ...]]¶

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

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

Вывод команды dumpdata может использоваться для команды loaddata.

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

--all, -a¶

Опция :djadminopt:`--all` позволяет указать dumpdata использовать базовый менеджер Django, чтобы исключить фильтрацию данных собственным менеджером модели.

--format FORMAT¶

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

--indent INDENT¶

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

--exclude EXCLUDE, -e EXCLUDE¶

Предотвращает сохранение определенных приложений или моделей (указанных в форме app_label.ModelName). Если вы укажете имя модели, будет исключена только эта модель, а не все приложение. Вы также можете смешивать имена приложений и названия моделей.

If you want to exclude multiple applications, pass --exclude more than once:

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

--database DATABASE¶

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

--natural-foreign¶

Если указана эта опция, Django будут использовать метод связанной модели natural_key() для внешних ключей и связей многое-ко-многим. Если вы делаете дамп contrib.auth Permission или contrib.contenttypes ContentType, вам следует использовать эту опцию. Подробности смотрите в разделе о натуральных ключах.

--natural-primary¶

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

--pks PRIMARY_KEYS¶

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

--output OUTPUT, -o OUTPUT¶

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

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

flush¶

django-admin flush¶

Удаляет все данные из базы данных, запускает «post-synchronization» обработчики. Таблица с выполненными миграциями не очищается.

If you would rather start from an empty database and re-run 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.

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

Сгенерированные модели будут содержать атрибут поля для каждого поля таблицы. Обратите внимание, есть несколько особенностей в работе этой команды:

Если inspectdb не может подобрать подходящий тип поля модели, будет использоваться поле TextField с комментарием в коде 'This field type is a guess.' возле этого поля.
Если название колонки в таблице входит в зарезервированные слова Python (такие как 'pass', 'class' или 'for'), inspectdb добавит '_field' к названию атрибута. Например, если таблица содержит колонку 'for', сгенерированная модель будет содержать поле 'for_field', с параметром db_column равным 'for'. inspectdb добавит комментарий в коде 'Field renamed because it was a Python reserved word.' возле поля.

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

Django не добавляет значение по умолчанию для колонки в таблице, если поле модели содержит default. Аналогично команда inspectdb не добавляет в поле модели значение по умолчанию из колонки в таблице.

По умолчанию inspectdb создает неуправляемые модели. То есть с managed=False``в классе ``Meta модели, что указывает Django не управляет созданием, изменением или удалением таблицы. Чтобы позволить Django управлять моделью, установите параметр managed в True (или просто удалите его, True является значением по умолчанию).

Фикстуры для определенной базы данных¶

Оракул¶

Модели создаются для материализованных представлений, если используется --include-views.

PostgreSQL¶

Модели создаются для сторонних таблиц.
Модели создаются для материализованных представлений, если используется --include-views.
Модели создаются для таблиц разделов, если используется --include-partitions.

--database DATABASE¶

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

--include-partitions¶

Если эта опция предусмотрена, модели также создаются для разделов.

Реализована только поддержка PostgreSQL.

--include-views¶

Если указана эта опция, модели также создаются для представлений базы данных.

`magenta`¶

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

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

--database DATABASE¶

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

--ignorenonexistent, -i¶

Опция :djadminopt:`--ignorenonexistent` позволяет игнорировать отсутствие полей в модели и моделей, если они были удалены после создания фикстуры.

--app APP_LABEL¶

Опция :djadminopt:`--app` позволяет указать приложение, которое будет использоваться для поиска фикстур. Без этой опции фикстуры ищутся во всех приложениях.

--format FORMAT¶

Указывает формат сериализации (например, json или xml) для приборов, читаемых из стандартного ввода.

--exclude EXCLUDE, -e EXCLUDE¶

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

What’s a «fixture»?¶

A fixture is a collection of files that contain the serialized contents of the database. Each fixture has a unique name, and the files that comprise the fixture can be distributed over multiple directories, in multiple applications.

Django will search in three locations for fixtures:

In the fixtures directory of every installed application
In any directory named in the FIXTURE_DIRS setting
In the literal path named by the fixture

Django will load any and all fixtures it finds in these locations that match the provided fixture names.

If the named fixture has a file extension, only fixtures of that type will be loaded. For example:

django-admin loaddata mydata.json

would only load JSON fixtures called mydata. The fixture extension must correspond to the registered name of a serializer (e.g., json or xml).

If you omit the extensions, Django will search all available fixture types for a matching fixture. For example:

django-admin loaddata mydata

would look for any fixture of any fixture type called mydata. If a fixture directory contained mydata.json, that fixture would be loaded as a JSON fixture.

The fixtures that are named can include directory components. These directories will be included in the search path. For example:

django-admin loaddata foo/bar/mydata.json

would search <app_label>/fixtures/foo/bar/mydata.json for each installed application, <dirname>/foo/bar/mydata.json for each directory in FIXTURE_DIRS, and the literal path foo/bar/mydata.json.

When fixture files are processed, the data is saved to the database as is. Model defined save() methods are not called, and any pre_save or post_save signals will be called with raw=True since the instance only contains attributes that are local to the model. You may, for example, want to disable handlers that access related fields that aren’t present during fixture loading and would otherwise raise an exception:

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)

You could also write a decorator to encapsulate this logic:

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

Just be aware that this logic will disable the signals whenever fixtures are deserialized, not just during loaddata.

Note that the order in which fixture files are processed is undefined. However, all fixture data is installed as a single transaction, so data in one fixture can reference data in another fixture. If the database backend supports row-level constraints, these constraints will be checked at the end of the transaction.

Для генерации фикстур для loaddata можно использовать команду dumpdata.

Compressed fixtures¶

Fixtures may be compressed in zip, gz, or bz2 format. For example:

django-admin loaddata mydata.json

would look for any of mydata.json, mydata.json.zip, mydata.json.gz, or mydata.json.bz2. The first file contained within a zip-compressed archive is used.

Note that if two fixtures with the same name but different fixture type are discovered (for example, if mydata.json and mydata.xml.gz were found in the same fixture directory), fixture installation will be aborted, and any data installed in the call to loaddata will be removed from the database.

MySQL with MyISAM and fixtures

The MyISAM storage engine of MySQL doesn’t support transactions or constraints, so if you use MyISAM, you won’t get validation of fixture data, or a rollback if multiple transaction files are found.

Database-specific fixtures¶

If you’re in a multi-database setup, you might have fixture data that you want to load onto one database, but not onto another. In this situation, you can add a database identifier into the names of your fixtures.

For example, if your DATABASES setting has a „master“ database defined, name the fixture mydata.master.json or mydata.master.json.gz and the fixture will only be loaded when you specify you want to load data into the master database.

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

You can use a dash as the fixture name to load input from sys.stdin. For example:

django-admin loaddata --format=json -

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

Loading from stdin is useful with standard input and output redirections. For example:

django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -

makemessages¶

django-admin makemessages¶

Анализирует все файлы в текущем каталоге и парсит строки, которые помечены для перевода. Создает (или обновляет) файл переводимых сообщений в conf/locale (в каталоге проекта) или каталоге переводов (для проекта или приложения). Чтобы использовать файлы перевода с помощью gettext, необходимо их скомпилировать командой compilemessages. Смотрите раздел о i18n

Эта команда не требует настроенных настроек. Однако, если настройки не настроены, команда не может игнорировать каталоги MEDIA_ROOT и STATIC_ROOT или включать LOCALE_PATHS.

--all, -a¶

Используйте опцию --all или -a чтобы обновить файлы перевода для всех языков.

--extension EXTENSIONS, -e EXTENSIONS¶

Specifies a list of file extensions to examine (default: html, txt, py or js if --domain is js).

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

django-admin makemessages --locale=de --extension xhtml

Separate multiple extensions with commas or use -e or --extension multiple times:

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¶

Опция --symlinks или -s позволяет указать следовать ли по символическим ссылкам при поиске файлов.

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

django-admin makemessages --locale=de --symlinks

--ignore PATTERN, -i PATTERN¶

По умолчанию используются следующие шаблоны: 'CVS', '.*', '*~', '*.pyc'

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

django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html

--no-default-ignore¶

Отключает значения по умолчанию --ignore.

--no-wrap¶

Опция --no-wrap позволяет отключить разбивку длинных сообщений на несколько строк в файле перевода.

--no-location¶

Опция --no-location позволяет отключить добавление „#: filename:line’ в файлы перевода. Обратите внимание, использование этой опции может усложнить работу технически образованным переводчикам, которым такие комментарии помогают понять смысл переводимого сообщения.

--add-location [{full,file,never}]¶

Управляет строками комментариев #:filename:line в языковых файлах. Если вариант:

full (по умолчанию, если не указано): строки включают как имя файла, так и номер строки.
файл: номер строки опущен.
никогда: строки подавляются (аналогично --no-location).

Требуется gettext 0.19 или новее.

--keep-pot¶

Опция --keep-pot указывает Django не удалять временные .pot файлы, которые создаются перед созданием .po файлов. Это полезно при отладке ошибок, которые мешают созданию файлов перевода.

См.также

В Настройка команды makemessages вы можете узнать как настроить параметры, которые makemessages передает в xgettext.

makemigrations [<app_label>]¶

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

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

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

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

--noinput, --no-input¶

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

--empty¶

Опция --empty укажет makemigrations создать пустую миграцию для последующего редактирования вручную. Эту опцию следует использоваться только продвинутым пользователям, которые хорошо знают как работают миграции в Django.

--dry-run¶

Опция --dry-run позволяет вывести все действия, которые будут выполнять создаваемые миграции, не создавая файл с миграцией. Если дополнительно указать --verbosity 3, будет выведено содержимое файлов миграций, которые будут созданы.

--merge¶

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

--name NAME, -n NAME¶

Опция --name позволяет указать миграции название.

--no-header¶

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

--check¶

Makes makemigrations exit with a non-zero status when model changes without migrations are detected.

`white`¶

django-admin migrate [app_label] [migration_name]¶

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

Поведение команды зависит от указанных аргументов:

Без аргументов: будет выполнена синхронизация всех приложений.
<app_label>: Будут выполнены миграции для указанного приложения до самой последней миграции. Это может вызвать миграцию других приложений через зависимости в миграциях.
<app_label> <migrationname>: Приводит базу данных к состоянию, которые было бы после завершения указанной миграции, но последующие миграции не выполнены. Обратите внимание, это может привести к отмене миграций, если были выполнены миграции, которые следуют после указанной вами. Используйте zero, чтобы отменить все миграции для приложения.

Предупреждение

При отмене миграции все зависимые миграции также будут отменены, независимо от <app_label>. Вы можете использовать --plan, чтобы проверить, какие миграции не будут применены.

--database DATABASE¶

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

--fake¶

Опция --fake указывает Django пометить миграции как выполненные/невыполненные без выполнения каких-либо SQL запросов.

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

--fake-initial¶

Опция --fake-initial позволяет Django пропустить начальную миграцию, если уже существуют все таблицы для моделей, которые указанны в операциях :class:`~django.db.migrations.operations.CreateModel`миграции. Эта опция создана для первого выполнения миграции на базе данных, которая существовала до создания миграций. Однако, эта опция не выполняет проверки соответствия структуры таблиц и моделей, поэтому следует использовать её, если вы уверены в правильности миграций.

--plan¶

Показывает операции миграции, которые будут выполнены для данной команды migrate.

--run-syncdb¶

Опция --run-syncdb позволяет создать таблицы для приложений без миграций. Хоть это и не рекомендуется, но миграции могут быть очень медленными для больших проектов с сотнями моделей.

--noinput, --no-input¶

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

--check¶

New in Django 3.1.

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

runserver¶

django-admin runserver [addrport]¶

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

Если вы запускаете команду как пользователь со стандартными правами (рекомендуется), у вас может не быть доступа к портам с малым номером. Такие порты зарезервированы для супер-пользователя (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 кода при необходимости. Нет необходимости перезапускать сервер при каждом изменении. Однако, некоторые изменения, такие как добавление файла, не вызывают перезапуск сервера, и вам необходимо сделать это самостоятельно.

If you’re using Linux or MacOS and install both pywatchman and the Watchman service, kernel signals will be used to autoreload the server (rather than polling file modification timestamps each second). This offers better performance on large projects, reduced response time after code changes, more robust change detection, and a reduction in power usage. Django supports pywatchman 1.2.0 and higher.

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

При использовании Watchman с проектом, который включает в себя большие каталоги, не относящиеся к Python, такие как node_modules, рекомендуется игнорировать этот каталог для оптимальной производительности. Информацию о том, как это сделать, см. в документации сторожа.

Тайм-аут сторожа

DJANGO_WATCHMAN_TIMEOUT¶

Тайм-аут клиента Watchman по умолчанию составляет 5 секунд. Вы можете изменить его, установив переменную среды DJANGO_WATCHMAN_TIMEOUT.

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.

Вы можете запустить несколько серверов, указав разные порты. Просто запустите 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) or 0.0.0.0 or :: (with IPv6 enabled).

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

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

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

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

--noreload¶

Опция --noreload позволяет отключить автоматическую перезагрузку сервера при изменении Python файлов.

--nothreading¶

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

--ipv6, -6¶

Опция --ipv6 (или короткий вариант -6) указывает Django использовать IPv6. IP адрес по умолчанию 127.0.0.1 будет заменен на ::1.

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

Port 8000 on IP address 127.0.0.1:

django-admin runserver

Port 8000 on IP address 1.2.3.4:

django-admin runserver 1.2.3.4:8000

Port 7000 on IP address 127.0.0.1:

django-admin runserver 7000

Port 7000 on IP address 1.2.3.4:

django-admin runserver 1.2.3.4:7000

Port 8000 on IPv6 address ::1:

django-admin runserver -6

Port 7000 on IPv6 address ::1:

django-admin runserver -6 7000

Port 7000 on IPv6 address 2001:0db8:1234:5678::9:

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

Port 8000 on IPv4 address of host localhost:

django-admin runserver localhost:8000

Port 8000 on IPv6 address of host localhost:

django-admin runserver -6 localhost:8000

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

По умолчанию сервер для разработки не раздает статические файлы (CSS файлы, изображения и другие файлы по адресу MEDIA_URL). Как настроить раздачу файлов можно узнать из раздела Managing static files (e.g. images, JavaScript, CSS).

sendtestemail¶

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

Sends a test email (to confirm email sending through Django is working) to the recipient(s) specified. For example:

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

Вы можете использовать любую комбинацию этих опций.

--managers¶

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

--admins¶

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

shell¶

django-admin shell¶

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

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

Django использует IPython или bpython, если они установлены. Если вы хотите использовать «обычный» интерпретатор Python, укажите опцию --plain:

IPython:

django-admin shell -i ipython

bpython:

django-admin shell -i bpython

If you have a «rich» shell installed but want to force use of the «plain» Python interpreter, use python as the interface name, like so:

django-admin shell -i python

--nostartup¶

Отключает чтение сценария запуска для «простого» интерпретатора Python. По умолчанию считывается сценарий, на который указывает переменная среды PYTHONSTARTUP, или скрипт ~/.pythonrc.py.

--command COMMAND, -c COMMAND¶

Lets you pass a command as a string to execute it as Django, like so:

django-admin shell --command="import django; print(django.__version__)"

Вы также можете передать код на стандартный ввод для его выполнения. Например:

$ django-admin shell <<EOF
> import django
> print(django.__version__)
> EOF

В Windows REPL выводится из-за ограничений реализации select.select() на этой платформе.

`**options`¶

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

Показывает все миграции в проекте.

--list, -l¶

Опция --list выведет все активированные приложения в проекте, список доступных миграций и пометки были ли они выполнены (знак [X] возле названия миграции).

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

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

Changed in Django 3.0:

Output of the applied datetimes at verbosity 2 and above was added.

--plan, -p¶

Опция --plan показывает план выполнения миграций, которому будет следовать Django для выполнения всех миграций. Указанные приложения игнорируются т.к. план выполнения миграций может содержать миграций из разных приложений. Как и для --list, выполненные миграции помечены [X]. При --verbosity 2 и выше будут выведены все зависимости миграции.

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

--database DATABASE¶

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

sqlflush¶

django-admin sqlflush¶

Выводить в консоль SQL запросы, которые будут выполнены при выполнении команды flush.

--database DATABASE¶

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

`white`¶

django-admin sqlmigrate app_label migration_name¶

Выводит в консоль SQL запросы для указанной миграции. Требует активного подключения к базе данных, чтобы определить доступны имена constraint(FIXME). Это значит, что вы должны создать SQL для копии базы данных, к которой будут применяться запросы.

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

--backwards¶

Генерирует SQL для отмены миграции. По умолчанию созданный SQL предназначен для запуска миграции в прямом направлении.

--database DATABASE¶

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

`sqlsequencereset`¶

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

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

Эти счетчики используются для определения следующего доступного номера.

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

--database DATABASE¶

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

`сквошмиграции`¶

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 пытается оптимизировать операции в миграциях, чтобы уменьшить размер файла. Опция --no-optimize позволяет отключить такое поведение, если оптимизация привела к созданию неправильной миграции, или ошибке при выполнении команды. Также мы просим сообщить об этом в баг-трекере Django.

--noinput, --no-input¶

Подавляет все запросы пользователя.

--squashed-name SQUASHED_NAME¶

Устанавливает имя сжатой миграции. Если этот параметр опущен, имя основано на первой и последней миграции с _squashed_ между ними.

--no-header¶

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

`стартап`¶

django-admin startapp name [directory]¶

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

По умолчанию созданный каталог содержит файл models.py и другие файлы шаблона приложения. (Смотрите исходный код). Если вы указали только название приложения, оно будет создано в текущем каталоге.

Если вы указали путь к каталогу, Django будет использовать его, вместо создания нового. Вы можете использовать „.“, чтобы указать текущий каталог.

Например:

django-admin startapp myapp /Users/jezdez/Code/myapp

--template TEMPLATE¶

Опция --template позволяет указать путь к своему шаблону приложения. Вы можете указать путь к каталогу или архиву (.tar.gz, .tar.bz2, .tgz, .tbz, .zip), который содержит файлы шаблона приложения.

For example, this would look for an app template in the given directory when creating the myapp app:

django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp

Django также позволяет указать URL (http, https, ftp) к архиву с шаблоном приложения, он будет автоматически загружен и распакован.

For example, taking advantage of GitHub’s feature to expose repositories as zip files, you can use a URL like:

django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip myapp

Changed in Django 3.0:

Support for XZ archives (.tar.xz, .txz) and LZMA archives (.tar.lzma, .tlz) was added.

--extension EXTENSIONS, -e EXTENSIONS¶

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

--name FILES, -n FILES¶

Указывает, какие файлы в шаблоне приложения (помимо тех, которые соответствуют --extension) должны отображаться с помощью механизма шаблонов. По умолчанию пустой список.

Контекст шаблона <django.template.Context>`, используемый для всех соответствующих файлов:

Все опции, переданные при вызове команды startapp (только поддерживаемые этой командой)
app_name – название приложение, указанное при вызове команды
app_directory – полный путь к созданному приложению
camel_case_app_name – название приложение в «camel case» формате
docs_version – версия документации: 'dev' или '1.x'
docs_version – версия документации: 'dev' или '1.x'

Предупреждение

При рендеринге файлов шаблона приложения (по умолчанию все *.py файлы) Django заменит все шаблонные переменные. Например, если какой-то Python файл содержит комментарий, описывающий примеры использования системы шаблонов Django, он может быть искажен в созданном приложении.

Чтобы избежать этого, используйте тег templatetag для «экранирования» синтаксиса шаблонов.

Кроме того, чтобы разрешить использование файлов шаблонов Python, содержащих синтаксис языка шаблонов Django, а также предотвратить попытки систем упаковки побайтно-компилировать недопустимые файлы *.py, файлы шаблонов, заканчивающиеся на .py-tpl, будут переименованы в .py.

`стартпроект`¶

django-admin startproject name [directory]¶

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

По умолчанию новый каталог содержит manage.py и пакет проекта (содержащий settings.py и другие файлы). Подробности смотрите в исходниках.

Если указано только название проекта, и каталог и Python пакет проекта будет называться <projectname>, и будут созданы в текущем каталоге.

Если указать необязательный путь к каталогу, Django будет использовать его как каталог проекта, создаст в нём manage.py и пакет проекта. Можно использовать „.“, чтобы указать текущий каталог.

Например:

django-admin startproject myproject /Users/jezdez/Code/myproject_repo

--template TEMPLATE¶

Как и для команды startapp, опция --template позволяет указать путь или URL к шаблону проекта. Подробности смотрите в описании startapp.

--extension EXTENSIONS, -e EXTENSIONS¶

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

--name FILES, -n FILES¶

Указывает, какие файлы в шаблоне проекта (помимо тех, которые соответствуют --extension) должны отображаться с помощью механизма шаблонов. По умолчанию пустой список.

Используемый контекст шаблона:

Все опции, переданные при вызове команды startproject (только поддерживаемые этой командой)
project_name – название проекта, указанное при вызове команды
project_directory – полный путь к созданному проекту
secret_key – случайный ключ для настройки SECRET_KEY
docs_version – версия документации: 'dev' или '1.x'
docs_version – версия документации: 'dev' или '1.x'

Please also see the rendering warning as mentioned for startapp.

`тест`¶

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

Выполняет тесты для всех установленных моделей(FIXME: models?). Смотрите Тестирование в Django.

--failfast¶

Опция --failfast позволяет остановить выполнение тестов после первой ошибки.

--testrunner TESTRUNNER¶

Опция --testrunner позволяет указать класс исполнителя тестов, который будет использоваться для запуска тестов. Указанное значение переопределяет значение настройки TEST_RUNNER.

--noinput, --no-input¶

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

runfcgi [options]¶

Команда test получает параметры от имени указанного --testrunner. Это параметры запуска тестов по умолчанию: DiscoverRunner.

--keepdb¶

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

--reverse, -r¶

Sorts test cases in the opposite execution order. This may help in debugging the side effects of tests that aren’t properly isolated. Grouping by test class is preserved when using this option.

--debug-mode¶

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

--debug-sql, -d¶

Опция --debug-sql позволяет включить логгирование SQL для «упавших» тестов. Если :djadminopt:`--verbosity` выше 2, будет логгированы запросы и успешно выполненных тестов.

--parallel [N]¶

DJANGO_TEST_PROCESSES¶

Опция --parallel позволяет запустить тесты параллельно в нескольких процессах. Т.к. современные процессоры состоят из нескольких ядер, это позволяет выполнять тесты значительно быстрее.

By default --parallel runs one process per core according to multiprocessing.cpu_count(). You can adjust the number of processes either by providing it as the option’s value, e.g. --parallel=4, or by setting the DJANGO_TEST_PROCESSES environment variable.

Django distributes test cases — unittest.TestCase subclasses — to subprocesses. If there are fewer test cases than configured processes, Django will reduce the number of processes accordingly.

Each process gets its own database. You must ensure that different test cases don’t access the same resources. For instance, test cases that touch the filesystem should create a temporary directory for their own use.

Примечание

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

Эта опция требует установить пакет tblib, чтобы правильно показывать трейсбек:

$ python -m pip install tblib

Этот функционал не работает на Windows. Также не работает с Oracle.

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

Предупреждение

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

Это известное ограничение. Вызвано необходимостью сериализировать объекты для передачи между процессами. Подробности смотрите в python:pickle-picklable.

--tag TAGS¶

Запускает только тесты, помеченные указанными тегами <topics-tagged-tests>. Может быть указано несколько раз и объединено с test --exclude-tag.

--exclude-tag EXCLUDE_TAGS¶

Исключает тесты, отмеченные указанными тегами <topics-tagged-tests>. Может быть указано несколько раз и объединено с test --tag.

-k TEST_NAME_PATTERNS¶

New in Django 3.0.

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

Python 3.7 and later

This feature is only available for Python 3.7 and later.

--pdb¶

New in Django 3.0.

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

--buffer, -b¶

New in Django 3.1.

Отменяет вывод (stdout и stderr) для прохождения тестов, так же, как unittest --buffer option.

`тестовый сервер`¶

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

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

For example, this command:

django-admin testserver mydata.json

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

Создаст тестовую базу данных, как описано вы Тестовая база данных.
Добавит в нее данных из указанных фикстур. (Подробности о фикстурах смотрите в описании loaddata.)
Запускает сервер Django для разработки (как и runserver), сервер будет использовать созданную тестовую базу данных.

Эта команда может быть полезна в следующих случаях:

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

Опция --addrport позволяет указать порт, или IP и порт, переопределив значение по умолчанию 127.0.0.1:8000. Формат значение аналогичен runserver.

Например:

To run the test server on port 7000 with fixture1 and fixture2:

django-admin testserver --addrport 7000 fixture1 fixture2
django-admin testserver fixture1 fixture2 --addrport 7000

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

To run on 1.2.3.4:7000 with a test fixture:

django-admin testserver --addrport 1.2.3.4:7000 test

--noinput, --no-input¶

Команды предоставленные приложениями¶

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

`django.contrib.auth`¶

changepassword¶

django-admin changepassword [<username>]¶

Эта команда работает только, если установлена система авторизации (django.contrib.auth).

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

--database DATABASE¶

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

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

django-admin changepassword ringo

createsuperuser¶

django-admin createsuperuser¶

DJANGO_SUPERUSER_PASSWORD¶

Эта команда работает только, если установлена система авторизации (django.contrib.auth).

Создает суперпользователя (пользователь со всеми правами). Можно использовать для создания самого первого суперпользователя, или чтобы программно создавать суперпользователей.

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

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

Changed in Django 3.0:

Support for using DJANGO_SUPERUSER_PASSWORD and DJANGO_SUPERUSER_<uppercase_field_name> environment variables was added.

--noinput, --no-input¶

--username USERNAME¶

--email EMAIL¶

Вы можете указать имя пользователя и email с помощью опций --username и --email. Если одна из опций не указана, createsuperuser попросит ввести значение, при запуске команды через консоль.

--database DATABASE¶

Опция --database позволяет указать базу данных, в которой будет создан новый пользователь.

Вы можете унаследоваться от команды и переопределить get_input_data(), если вы хотите настроить данные для ввода и их проверку. Детали реализации и параметры вы можете найти в исходном коде. Например, это может пригодиться, если у вас есть ForeignKey в REQUIRED_FIELDS и вы хотите создавать экземпляр вместо того, чтобы указывать первичный ключ существующего связанного объекта.

`django.contrib.sitemaps`¶

`remove_stale_contenttypes`¶

django-admin remove_stale_contenttypes¶

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

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

--database DATABASE¶

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

--include-stale-apps¶

New in Django 3.1.

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

`django.contrib.gis`¶

ogrinspect¶

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

Подробности смотрите в документации GeoDjango.

`django.contrib.sessions`¶

clearsessions¶

django-admin clearsessions¶

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

`django.contrib.sitemaps`¶

`ping_google`¶

This command is only available if the Sitemaps framework (django.contrib.sitemaps) is installed.

Please refer to its description in the Sitemaps documentation.

`django.contrib.staticfiles`¶

collectstatic¶

Команда доступна, если установлено приложение для работы со статикой (django.contrib.staticfiles).

Смотрите описание команды в разделе staticfiles.

findstatic¶

Команда доступна, если установлено приложение для работы со статикой (django.contrib.staticfiles).

Смотрите описание команды в разделе staticfiles.

Опции по умолчанию¶

Although some commands may allow their own custom options, every command allows for the following options:

--pythonpath PYTHONPATH¶

Adds the given filesystem path to the Python import search path. If this isn’t provided, django-admin will use the PYTHONPATH environment variable.

Обратите внимание, эта опция не обязательна при использовании manage.py, т.к. он сам устанавливает необходимые пути поиска Python.

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

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

--settings SETTINGS¶

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

Обратите внимание, эта опция не обязательна при использовании manage.py, т.к. он использует settings.py текущего проекта.

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

django-admin migrate --settings=mysite.settings

--traceback¶

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

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

django-admin migrate --traceback

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

Опция --verbosity позволяет указать уровень вывода в консоль сообщений и отладочной информации для django-admin.

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

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

django-admin migrate --verbosity 2

--no-color¶

По умолчанию django-admin использует цвета для форматирования вывода. Например, ошибки выводятся красным, а для SQL запросов используется подсветка синтаксиса. Чтобы отключить цветной вывод, используйте опцию --no-color.

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

django-admin runserver --no-color

--force-color¶

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

--skip-checks¶

New in Django 3.0.

Skips running system checks prior to running the command. This option is only available if the requires_system_checks command attribute is set to True.

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

django-admin migrate --skip-checks

Дополнительные возможности¶

Подсветка синтаксиса¶

DJANGO_COLORS¶

Команды django-admin / manage.py использует цветной вывод, если терминал поддерживает ANSI-цветной вывод. Если вывод передается в другую команду через «pipe»(|), цветной выводе не будет использоваться.

Under Windows, the native console doesn’t support ANSI escape sequences so by default there is no color output. But you can install the ANSICON third-party tool, the Django commands will detect its presence and will make use of its services to color output just like on Unix-based platforms.

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

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

You select a palette by setting a DJANGO_COLORS environment variable to specify the palette you want to use. For example, to specify the light palette under a Unix or OS/X BASH shell, you would run the following at a command prompt:

export DJANGO_COLORS="light"

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

error - Важная ошибка.
notice - Незначительная ошибка.
success - Без ошибок.
warning - Предупреждение.
sql_field - Название поля модели в SQL.
sql_coltype - Тип поля модели в SQL.
sql_keyword - Ключевые слова SQL.
sql_table - Название модели в SQL.
http_info - 1XX HTTP Informational ответ сервера.
http_success - 2XX HTTP Success ответ сервера.
http_not_modified - 304 HTTP Not Modified ответ сервера.
http_redirect - 3XX HTTP Redirect ответ сервера, исключая 304.
http_not_found - 404 HTTP Not Found ответ сервера.
http_bad_request - 4XX HTTP Bad Request ответ сервера, исключая 404.
http_server_error - 5XX HTTP Server Error ответ сервера.
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

where role is the name of a valid color role, fg is the foreground color, bg is the background color and each option is one of the color modifying options. Multiple color specifications are then separated by a semicolon. For example:

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

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

Colors can also be specified by extending a base palette. If you put a palette name in a color specification, all the colors implied by that palette will be loaded. So:

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

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

Автодополнение в 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.

Смотрите Writing custom django-admin commands о том, как добавить свои команды.

Выполнение команд в коде¶

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

To call a management command from code use 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 createuperuser --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)

Базы данных

Исключения Django

django-admin и manage.py¶

Использование¶

Как отобразить помощь¶

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

Получаем текущую версию Django¶

Вывод отладочной информации¶

Доступные команды¶

black¶

compilemessages¶

createcachetable¶

dbshell¶

diffsettings¶

magenta¶

flush¶

inspectdb¶

Фикстуры для определенной базы данных¶

Оракул¶

PostgreSQL¶

magenta¶

What’s a «fixture»?¶

Compressed fixtures¶

Database-specific fixtures¶

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

makemessages¶

makemigrations [<app_label>]¶

white¶

runserver¶

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

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

sendtestemail¶

shell¶

**options¶

sqlflush¶

white¶

sqlsequencereset¶

сквошмиграции¶

стартап¶

стартпроект¶

тест¶

runfcgi [options]¶

тестовый сервер¶

Команды предоставленные приложениями¶

django.contrib.auth¶

changepassword¶

createsuperuser¶

django.contrib.sitemaps¶

remove_stale_contenttypes¶

django.contrib.gis¶

ogrinspect¶

django.contrib.sessions¶

clearsessions¶

django.contrib.sitemaps¶

ping_google¶

django.contrib.staticfiles¶

collectstatic¶

findstatic¶

Опции по умолчанию¶

Дополнительные возможности¶

Подсветка синтаксиса¶

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

Выполнение команд в коде¶

Перенаправление вывода¶

Дополнительная информация

Содержание

Просмотр

Вы находитесь здесь:

Получить помощь

`black`¶

`magenta`¶

`magenta`¶

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

`white`¶

`**options`¶

`white`¶

`sqlsequencereset`¶

`сквошмиграции`¶

`стартап`¶

`стартпроект`¶

`тест`¶

`тестовый сервер`¶

`django.contrib.auth`¶

`django.contrib.sitemaps`¶

`remove_stale_contenttypes`¶

`django.contrib.gis`¶

`django.contrib.sessions`¶

`django.contrib.sitemaps`¶

`ping_google`¶

`django.contrib.staticfiles`¶