django-admin.py и manage.py

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

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

  • Добавляет пакет проекта в sys.path.

  • Устанавливает переменную окружения DJANGO_SETTINGS_MODULE, чтобы она указывала на файл settings.py проекта.

  • Вызывает django.setup() для инициализации Django.

Добавлено в Django 1.7:

django.setup() отсутствовала в предыдущих версиях Django.

Если вы установили Django через setup.py, скрипт django-admin.py уже должен находиться в путях поиска(переменная окружения PATH) вашей системы. Если система не может его найти, поищите его в подкаталоге site-packages/django/bin каталога установленного Python. Вы можете создать симлинк на скрипт в каталоге, который находится в путях поиска системы, например /usr/local/bin.

Пользователи Windows, где нет симлинков, могут скопировать django-admin.py в каталог, который уже находится в путях поиска системы, или отредактировать переменную окружения PATH (можно найти через Settings - Control Panel - System - Advanced - Environment...) и добавить каталог с установленным django-admin.py.

При работе с одним проектом Django удобнее использоваться manage.py, чем django-admin.py. Если вам необходимо переключаться между различными фалами настройки, используйте django-admin.py с переменной окружения DJANGO_SETTINGS_MODULE или опцией --settings.

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

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

$ django-admin.py <command> [options]
$ manage.py <command> [options]

command – одна из команд, описанных в этом разделе. options – необязательные опции команды.

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

django-admin.py help

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

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

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

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

Большая часть команд принимает список “названий приложений”. “Название приложения” – это название основного пакета приложения. Например, если настройка INSTALLED_APPS содержит строку 'mysite.blog', название приложения будет blog.

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

django-admin.py version

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

Вывод соответствует формату, описанному в PEP 386:

1.4.dev17026
1.4a1
1.4

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

Укажите --verbosity, чтобы определить уровень выводимых в консоль django-admin.py уведомлений и отладочной информации. Подробности смотрите в описании опции --verbosity.

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

check <appname appname ...>

django-admin.py check
Изменено в Django 1.7.

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

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

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

python manage.py check auth admin myapp

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

--tag <tagname>

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

python manage.py check --tag security --tag compatibility
--list-tags

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

compilemessages

django-admin.py compilemessages

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

Вы можете указать список локалей с помощью опции --locale (сокращенный вариант -l). Если опция не указана, будут обработаны все локали.

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

django-admin.py compilemessages --locale=pt_BR
django-admin.py compilemessages --locale=pt_BR --locale=fr
django-admin.py compilemessages -l pt_BR
django-admin.py compilemessages -l pt_BR -l fr
Изменено в Django 1.6:

Добавлена возможность указать несколько локалей.

createcachetable

django-admin.py createcachetable

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

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

Изменено в Django 1.7:

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

dbshell

django-admin.py dbshell

Запускает консольный клиент для подключения к базе данных. Консольный клиент определяется настройкой ENGINE, параметры подключения – настройками USER, PASSWORD, и т.д.

  • Для PostgreSQL используется консольный клиент psql .

  • Для MySQL используется mysql.

  • Для SQLite используется sqlite3.

Эта команда подразумевает, что клиент находится в PATH системы, и запуск клиента в консоли (psql, mysql, sqlite3) работает. Нет способа указать путь к клиенту.

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

diffsettings

django-admin.py diffsettings

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

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

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

Добавлено в Django 1.6:

Была добавлена опция --all.

dumpdata <app_label app_label app_label.Model ...>

django-admin.py dumpdata

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

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

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

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

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

--format <fmt>

По умолчанию dumpdata будет выводить данные в формате JSON. Вы можете указать другой формат с помощью опции --format. Доступные форматы описаны в Serialization formats.

--indent <num>

По умолчанию dumpdata выведет все данные одной строкой. Это не очень удобно для понимая человеком. Для читабельного вывода вы можете указать опцию --indent. Указанное значение будет использоваться как величина отступа.

Опция --exclude позволяет исключить определенные приложения или модели (формат значений – app_label.ModelName). Если в аргументах dumpdata указать модель, будет выведен дамп данных только для этой модели, а не всего приложения. Вы можете указать модели и приложения вместе.

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

--natural-foreign
Добавлено в Django 1.7.

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

--natural-primary
Добавлено в Django 1.7.

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

--natural

Не рекомендуется, начиная с версии 1.7: Аналог опции --natural-foreign, используйте её вместо этой опции.

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

Добавлено в Django 1.6.
--pks

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

flush

django-admin.py flush

Удаляет все данные из базы данных, запускает “post-synchronization” обработчики и загружает начальные данные из фикстур.

Опция --noinput отключить вывод в консоль.

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

--no-initial-data

Опция --no-initial-data позволяет отключить загрузку начальных данных из “initial_data” фикстур.

inspectdb

django-admin.py inspectdb

Анализирует таблицы в базе данных, указанной настройкой NAME, и выводит сгенерированные модели Django.

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

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

  • Если 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.' возле поля.

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

Первичные ключи автоматически определяются для PostgreSQL, MySQL и SQLite, и Django добавит для соответствующих полей primary_key=True.

inspectdb работает с PostgreSQL, MySQL и SQLite. Определение внешних ключей работает только для PostgreSQL и некоторых типов таблиц MySQL.

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

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

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

Изменено в Django 1.6:

Созданные модели содержат managed=False с Django 1.6.

loaddata <fixture fixture ...>

django-admin.py loaddata

Ищет и загружает указанные фикстуры в базу данных.

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

--ignorenonexistent

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

Изменено в Django 1.7:

Была добавлена опция --app.

--app

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

Что такое “фикстура”?

Фикстура – это файл с сериализированными данными из базы данных. У каждой фикстуры уникальное название Фикстуры могут находиться в различных каталогах и приложениях.

Django ищет фикстуры в следующих местах:

  1. В каталоге fixtures установленных приложений

  2. В каталогах, указанных в настройке FIXTURE_DIRS

  3. Путь, которые содержится в названии фикстуры

Django загрузит все фикстуры, которые найдет по указанному названию.

Если название фикстуры содержит расширение файла, только фикстуры этого типа будут загружены. Например:

django-admin.py loaddata mydata.json

загрузит только JSON фикстуры с названием mydata. Расширение фикстуры должно соответствовать одному из доступных сериалайзеров (например, json или xml).

Если расширение не указано в названии фикстуры, Django будет искать фикстуры всех возможных типов. Например:

django-admin.py loaddata mydata

выполнит поиск фикстуры с названием mydata и с любым типом. Если каталог фикстур содержит mydata.json, этот файл будет загружен как JSON фикстура.

Название фикстуры может содержать относительный путь. Он будет использоваться при поиске фкистуры. Например:

django-admin.py loaddata foo/bar/mydata.json

выполнит поиск в <app_label>/fixtures/foo/bar/mydata.json в каждом установленном приложении, <dirname>/foo/bar/mydata.json – для каждого каталога из FIXTURE_DIRS, и foo/bar/mydata.json.

После обработки фикстур данные будут загружены непосредственно в базу данных. Метод save() модели не будет вызван. Обработчики сигналов pre_save и post_save будут вызваны с аргументом raw=True т.к. экземпляр модели содержит только локальные атрибуты. Вы можете, например, отключить обработчик, который обращается к внешним ключам т.к. они не определены при загрузке фикстуры, что вызовет исключение:

from django.db.models.signals import post_save
from .models import MyModel

def my_handler(**kwargs):
    # disable the handler during fixture loading
    if kwargs['raw']:
        return
    ...

post_save.connect(my_handler, sender=MyModel)

Также вы можете для этого создать простой декоратор:

from functools import wraps

def disable_for_loaddata(signal_handler):
    """
    Decorator that turns off signal handlers when loading fixture data.
    """
    @wraps(signal_handler)
    def wrapper(*args, **kwargs):
        if kwargs['raw']:
            return
        signal_handler(*args, **kwargs)
    return wrapper

@disable_for_loaddata
def my_handler(**kwargs):
    ...

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

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

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

Сжатые фикстуры

Фикстуры могут быть сжаты в zip, gz или bz2 архив. Например:

django-admin.py loaddata mydata.json

будет искать mydata.json, mydata.json.zip, mydata.json.gz или mydata.json.bz2. Первый файл из архива будет загружен как фикстура.

Обратите внимание, если найдено две фикстуры с одинаковым именем, но разного формата (например, mydata.json и mydata.xml.gz были найдены в одном каталоге), загрузка фикстур будет остановлена, и загруженные loaddata до этого данные будет удалены из базы данных.

MySQL с MyISAM и фикстуры

Хранилище MyISAM в MySQL не поддерживает транзакции и проверку внешних ключей. Если вы используйете MyISAM, проверка данных из фикстур не будет выполнена, как и откат изменений, если было найдено несколько фикстур с одинаковыми названиями.

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

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

Например, если настройка DATABASES содержит базу данных ‘master’, назовите фикстуру mydata.master.json или mydata.master.json.gz и она будет загружена в базу данных master.

makemessages

django-admin.py makemessages

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

--all

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

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

django-admin.py makemessages --all
--extension

С помощью опции --extension или -e можно указать список расширений файлов, которые будут обрабатываться командой (по умолчанию: ”.html”, ”.txt”).

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

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

Вы можете укать несколько расширений через запятую, или указав опцию -e или –extension несколько раз:

django-admin.py makemessages --locale=de --extension=html,txt --extension xml

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

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

django-admin.py makemessages --locale=pt_BR
django-admin.py makemessages --locale=pt_BR --locale=fr
django-admin.py makemessages -l pt_BR
django-admin.py makemessages -l pt_BR -l fr
Изменено в Django 1.6:

Добавлена возможность указать несколько локалей.

Изменено в Django 1.7:

Была добавлена опция --previous для команды msgmerge, которая используется для создания po файлов.

--domain

Опция --domain или -d позволяет изменить “домен” файлов перевода. Поддерживается:

  • django для *.py, *.html и *.txt файлов (по умолчанию)

  • djangojs для файлов *.js

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

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

django-admin.py makemessages --locale=de --symlinks
--ignore

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

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

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

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

Опция --no-default-ignore позволяет отключить значения по умолчанию для --ignore.

--no-wrap

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

--no-location

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

--keep-pot
Добавлено в Django 1.6.

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

makemigrations [<app_label>]

django-admin.py makemigrations
Добавлено в Django 1.7.

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

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

Опция --noinput отключить вывод в консоль.

--empty

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

--dry-run

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

--merge

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

migrate [<app_label> [<migrationname>]]

django-admin.py migrate
Добавлено в Django 1.7.

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

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

  • Без аргументов: будет выполнена синхронизация всех приложений,

  • <app_label>: Будут выполнены миграции для указанного приложения до самой последней миграции. Это может вызвать миграцию других приложений через зависимости в миграциях.

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

В отличии от syncdb эта команда не пытается создать супер-пользователя, если такой не существует (подразумевается, что вы используете django.contrib.auth). Для этого используйте команду createsuperuser.

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

--fake

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

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

--list, -l

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

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

runfcgi [options]

django-admin.py runfcgi

Не рекомендуется, начиная с версии 1.7: Поддержка FastCGI устарела и будет удалена в Django 1.9.

Запускает несколько совместимых с FastCGI процессов, которые могут использоваться с Web-сервером, который поддерживает FastCGI протокол. Смотрите раздел о FastCGI. Требует FastCGI Python модуль из flup.

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

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

protocol

protocol=PROTOCOL

Используемый протокол. PROTOCOL может быть fcgi, scgi, ajp и т.д.. (по умолчанию fcgi)

host

host=HOSTNAME

Имя хоста.

port

port=PORTNUM

Номер порта.

socket

socket=FILE

UNIX-сокет.

method

method=IMPL

Доступные значения: prefork или threaded (по умолчанию prefork)

maxrequests

maxrequests=NUMBER

Количество запросов после которого будет перезапущен дочерний процесс (0 - неограниченное количество запрос).

maxspare

maxspare=NUMBER

Максимальное количество “запасных” процессов / потоков.

minspare

minspare=NUMBER

Минимальное количество “запасных” процессов / потоков.

maxchildren

maxchildren=NUMBER

Лимит на количество процессов / потоков.

daemonize

daemonize=BOOL

“Отвязать” ли от терминала.

pidfile

pidfile=FILE

Записать ID процесса в файл FILE.

workdir

workdir=DIRECTORY

Переключиться на каталог DIRECTORY при создании процесса-демона.

debug

debug=BOOL

Укажите true, чтобы включить полный трейсбек в flup.

outlog

outlog=FILE

Записывать stdout в файл FILE.

errlog

errlog=FILE

Записывать stderr в файл FILE.

umask

umask=UMASK

Umask, которая будет использоваться при “демонизации” процесс. Значение должно быть восьмеричным числом (по умолчанию 0o22).

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

django-admin.py runfcgi socket=/tmp/fcgi.sock method=prefork daemonize=true \
    pidfile=/var/run/django-fcgi.pid

Запускает FastCGI сервер как демон и записывает PID в файл.

runserver [port или address:port]

django-admin.py runserver

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

Если вы запускаете команду как пользователь со стандартными правами (рекомендуется), у вас может не быть доступа к портам с малым номером. Такие порты зарезервированы для супер-пользователя (root).

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

НЕ ИСПОЛЬЗУЙТЕ ЭТОТ СЕРВЕР НА БОЕВОМ СЕРВЕРЕ. Этот сервер не анализировался на предмет уязвимостей и не подвергался тестам производительности. (И так оно и будет. Мы умеем делать Web-фреймворки, не Web-серверы, по этому доработка этого сервера не входит в наши задачи.)

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

Изменено в Django 1.7:

Компилирование файлов перевода теперь перезапускает сервер для разработки.

Если вы используете Linux и установили pyinotify, будут использоваться kernel signals для перезапуска сервера (вместо мониторинга времени изменения файлов). Это улучшает производительность для больших проектов, уменьшает время реакции на изменения кода, более надежное обнаружение изменений, и уменьшает потребление заряда батареи.

Добавлено в Django 1.7:

Была добавлена поддержка pyinotify.

После запуска сервера при каждом изменении Python кода, сервер будет проверять весь Django проект на предмет ошибок (смотрите описание команды check). Ошибки будут выведены в консоль, но сервер не будет остановлен.

Вы можете запустить несколько серверов, указав разные порты. Просто запустите django-admin.py runserver несколько раз.

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

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

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

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

--noreload

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

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

django-admin.py runserver --noreload
--nothreading

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

--ipv6, -6

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

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

django-admin.py runserver --ipv6

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

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

django-admin.py runserver

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

django-admin.py runserver 1.2.3.4:8000

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

django-admin.py runserver 7000

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

django-admin.py runserver 1.2.3.4:7000

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

django-admin.py runserver -6

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

django-admin.py runserver -6 7000

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

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

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

django-admin.py runserver localhost:8000

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

django-admin.py runserver -6 localhost:8000

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

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

shell

django-admin.py shell

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

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

django-admin.py shell --plain

Если у вас установлен IPython и bpython, вы можете явно указать какой использовать с помощью опции -i или --interface:

IPython:

django-admin.py shell -i ipython
django-admin.py shell --interface ipython

bpython:

django-admin.py shell -i bpython
django-admin.py shell --interface bpython

При запуске “обычного” интерпретатора Python, он выполняет скрипт, указанный в переменной окружения PYTHONSTARTUP, а также скрипт ~/.pythonrc.py. Опция --no-startup позволяет отключить такое поведение:

django-admin.py shell --plain --no-startup
Добавлено в Django 1.6:

Опция --no-startup была добавлена в Django 1.6.

sql <app_label app_label ...>

django-admin.py sql

Выводит в консоль CREATE TABLE SQL запросы для указанных приложений.

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

sqlall <app_label app_label ...>

django-admin.py sqlall

Выводит в консоль CREATE TABLE и все инициализирующие SQL запросы для указанных приложений.

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

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

Изменено в Django 1.7:

Команды sql* теперь учитывают метод allow_migrate() объектов из настройки DATABASE_ROUTERS. Если у вас есть модели, которые синхронизированы не в базу данных по умолчанию, используйте опцию --database, чтобы получить SQL для этих моделей (ранее они всегда включались в вывод команды).

sqlclear <app_label app_label ...>

django-admin.py sqlclear

Выводит в консоль DROP TABLE SQL запросы для указанных приложений.

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

sqlcustom <app_label app_label ...>

django-admin.py sqlcustom

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

Для каждой модели указанных приложений эта команда ищет файл <app_label>/sql/<modelname>.sql, где <app_label> - название приложения, а <modelname> - название модели в нижнем регистре. Например, для приложения news и модели Story, sqlcustom будет искать файл news/sql/story.sql и добавит его содержимое в результат выполнения команды.

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

Обратите внимание, порядок, в котором загружаются SQL файлы, не определен.

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

sqldropindexes <app_label app_label ...>

django-admin.py sqldropindexes
Добавлено в Django 1.6.

Выводит в консоль DROP INDEX SQL запросы для указанных приложений.

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

sqlflush

django-admin.py sqlflush

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

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

sqlindexes <app_label app_label ...>

django-admin.py sqlindexes

Выводит в консоль CREATE INDEX SQL запросы для указанных приложений.

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

sqlmigrate <app_label> <migrationname>

django-admin.py sqlmigrate

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

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

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

--backwards

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

sqlsequencereset <app_label app_label ...>

django-admin.py sqlsequencereset

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

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

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

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

squashmigrations <app_label> <migration_name>

django-admin.py squashmigrations

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

--no-optimize

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

startapp <app_label> [destination]

django-admin.py startapp

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

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

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

Например:

django-admin.py startapp myapp /Users/jezdez/Code/myapp
--template

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

Например:

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

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

Например, используя возможность Github-а предоставлять zip-архив с кодом репозитория, вы можете использовать следующий URL:

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

Когда Django копирует файлы, он может рендерить определенные файлы как шаблоны Django: все файлы с расширением, указанным опцией --extension (по умолчанию py), и файлы с названием, указанным опцией --name. При рендеринге используется template context со следующими переменными:

  • Все опции, переданные при вызове команды startapp (только поддерживаемые этой командой)

  • app_name – название приложение, указанное при вызове команды

  • app_directory – полный путь к созданному приложению

  • docs_version – версия документации: 'dev' или '1.x'

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

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

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

startproject <projectname> [destination]

django-admin.py startproject

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

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

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

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

Например:

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

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

Например, следующая команда будет использоваться указанный шаблон для создания проекта myproject:

django-admin.py startproject --template=/Users/jezdez/Code/my_project_template myproject

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

Например, используя возможность Github-а предоставлять zip-архив с кодом репозитория, вы можете использовать следующий URL:

django-admin.py startproject --template=https://github.com/githubuser/django-project-template/archive/master.zip myproject

Когда Django копирует файлы шаблона проекта, он может рендерить определенные файлы как шаблоны Django: все файлы с расширением, указанным опцией --extension (по умолчанию py), и файлы с названием, указанным опцией --name. При рендеринге используется template context со следующими переменными:

  • Все опции, переданные при вызове команды startproject (только поддерживаемые этой командой)

  • project_name – название проекта, указанное при вызове команды

  • project_directory – полный путь к созданному проекту

  • secret_key – случайный ключ для настройки SECRET_KEY

  • docs_version – версия документации: 'dev' или '1.x'

Обратите внимание на возможные проблемы при рендеринге, описанные в команде startapp.

syncdb

django-admin.py syncdb

Не рекомендуется, начиная с версии 1.7: Эта команда устарела, используйте migrate, которая включает старые функции и выполнение миграций. Теперь это просто синоним новой команды.

Синоним для migrate.

test <app или test identifier>

django-admin.py test

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

--failfast

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

--testrunner

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

--liveserver

Опция --liveserver позволяет переопределить адрес по умолчанию для тестового сервера (используется с LiveServerTestCase). По умолчанию используется localhost:8081.

testserver <fixture fixture ...>

django-admin.py testserver

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

Например:

django-admin.py testserver mydata.json

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

  1. Создаст тестовую базу данных, как описано вы Тестовая база данных.

  2. Добавит в нее данных из указанных фикстур. (Подробности о фикстурах смотрите в описании loaddata.)

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

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

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

  • Предположим вы разрабатываете приложение и у вас есть “нетронутая” копия базы данных, с которой вы хотите работать. Вы можете сделать дамп базы в фикстуру (используя команду dumpdata), затем запустить testserver с этими данными. С тестовым сервером вы можете как угодно менять данные, зная, что все изменения применяются к тестовой базе данных.

Обратите внимание, этот сервер не определяет изменения в Python файлах (как это делает команда runserver). Однако, он отслеживает изменения в шаблонах.

--addrport [port number or ipaddr:port]

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

Например:

Чтобы запустить тестовый сервер на 7000 порту с фикстурами fixture1 и fixture2:

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

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

Чтобы запустить сервер на 1.2.3.4:7000 с фикстурой test:

django-admin.py testserver --addrport 1.2.3.4:7000 test

Опция --noinput отключить вывод в консоль.

validate

django-admin.py validate

Не рекомендуется, начиная с версии 1.7: Заменена командой check.

Проверяет все установленные модели (в соответствии с настройкой INSTALLED_APPS) и выводит ошибки валидации.

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

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

django.contrib.auth

changepassword

django-admin.py changepassword

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

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

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

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

django-admin.py changepassword ringo

createsuperuser

django-admin.py createsuperuser

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

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

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

--username
--email

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

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

django.contrib.gis

ogrinspect

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

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

django.contrib.sessions

clearsessions

django-admin.py clearsessions

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

django.contrib.sitemaps

ping_google

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

Смотрите описание в документации Sitemap.

django.contrib.staticfiles

collectstatic

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

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

findstatic

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

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

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

Каждая команда принимает ряд стандартных опций:

--pythonpath

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

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

Добавляет указанный путь в пути поиска Python. Если опция не указан, django-admin.py будет использовать переменную окружения PYTHONPATH.

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

--settings

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

django-admin.py migrate --settings=mysite.settings

Опция позволяет явно указать модуль настроек, который следует использовать. Путь к модулю должен быть в Python формате, например mysite.settings. Если опция не указана, django-admin.py будет использовать значение переменной окружения DJANGO_SETTINGS_MODULE.

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

--traceback

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

django-admin.py migrate --traceback

По умолчанию django-admin.py покажет сообщение ошибки для CommandError, и полный трейсбек для остальных ошибок. Опция --traceback указывает django-admin.py выводить полный трейсбек и для CommandError.

Изменено в Django 1.6:

Ранее Django не показывал трейсбек для ошибок отличных от CommandError.

--verbosity

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

django-admin.py migrate --verbosity 2

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

  • 0 – ничего не выводить.

  • 1 – обычный вывод (по умолчанию).

  • 2 – подробный вывод.

  • 3очень подробный вывод.

--no-color
Добавлено в Django 1.7.

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

django-admin.py sqlall --no-color

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

Общие опции

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

--database

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

Например, выполнить дамп данных из базы данных с меткой master:

django-admin.py dumpdata --database=master
--exclude

Позволяет исключить приложение из вывода. Например, чтобы исключить приложение auth из вывода dumpdata, выполните:

django-admin.py dumpdata --exclude=auth

Чтобы исключить несколько приложений, используйте --exclude несколько раз:

django-admin.py dumpdata --exclude=auth --exclude=contenttypes
--locale

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

--noinput

Опция --noinput позволяет отключить все запросы на ввод, такие как просьба подтвердить действия “Are you sure?”. Полезна, если django-admin.py запускает не с консоли, а автоматическим скриптом.

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

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

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

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

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

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

  • light, для терминалов, которые выводят черный текст на белом фоне.

  • nocolor, отключает подсветку синтаксиса.

Вы можете указать цветную тему, используя переменную окружения DJANGO_COLORS. Например, чтобы использовать light тему в Unix или OS/X BASH, выполните:

export DJANGO_COLORS="light"

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

  • error - Важная ошибка.

  • notice - Незначительная ошибка.

  • 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 ответ сервера.

Для каждого сообщения можно указать цвет текста и фона. Доступные цвета:

  • black
  • red
  • green
  • yellow
  • blue
  • magenta
  • cyan
  • white

Можно указать дополнительно следующие параметры:

  • bold
  • underscore
  • blink
  • reverse
  • conceal

Цвета можно указать в следующем формате:

  • role=fg
  • role=fg/bg
  • role=fg,option,option
  • role=fg/bg,option,option

где role – это тип сообщения, fg – цвет текста, bg – цвет фона, а каждая option – один из дополнительных параметров. Настройки для нескольких типов сообщений можно указать через точку с запятой. Например:

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

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

Цвета можно унаследовать от существующей цветовой темы, указав ее название в переменной. Например:

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

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

Добавлено в Django 1.7.

Добавлена поддержка цветного вывода django-admin.py / manage.py на Windows с использованием ANSICON.

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

Если вы используете Bash, вы можете установить скрипт автодополнения для Django, который находится в extras/django_bash_completion в пакете Django. Он позволяет автодополнение команд через [TAB] для django-admin.py и manage.py. Теперь вы можете, например...

  • Ввести django-admin.py.

  • Нажать [TAB], чтобы увидеть все доступные команды.

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

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

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

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

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

name

Название команды.

*args

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

**options

Список опций для команды.

Например:

from django.core import management
management.call_command('flush', verbosity=0, interactive=False)
management.call_command('loaddata', 'test_data', verbosity=0)

Обратите внимание, опции, которые не принимают аргументы, указываются как именованные аргументы функции с True или False:

management.call_command('dumpdata', use_natural_keys=True)

Опции, которые принимают несколько значений, передаются через список:

management.call_command('dumpdata', exclude=['contenttypes', 'auth'])

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

Обратите внимание, вы можете перенаправить вывод команды т.к. все команды поддерживают опции stdout и stderr. Например:

with open('/tmp/command_output') as f:
    management.call_command('dumpdata', stdout=f)