django-admin と manage.py

django-admin は Django の管理タスクのためのコマンドラインユーティリティです。このドキュメントでは、その機能の全体を一通り説明します。

さらに、manage.py は各 Django プロジェクト内に自動的に作成されます。jango-admin と同じことができますが、DJANGO_SETTINGS_MODULE を設定することもでき、プロジェクトの settings.py を指定できます。

Django を pip 経由でインストールした場合、 django-admin はシステムパス上に設定されているはずです。もしシステムパスにない場合、仮想環境が有効になっていることを確認してください。

通常、単体の Django プロジェクトを用いる場合、django-admin よりも manage.py の方が簡単に利用できます。もし複数の Django 設定ファイル間での切り替えが必要な場合は、django-admin を DJANGO_SETTINGS_MODULE もしくは --settings オプションと共に利用してください。

本項ではコマンドラインの実行例は一貫して django-admin を使用しますが、実行例は全て manage.py もしくは python -m django でも同様に利用可能です。

使い方

Linux/macOS

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

Windows

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

command にはこのドキュメントに一覧されたコマンドの1つでなければなりません。options はオプションで、与えられたコマンドで利用できる 0 個以上のオプションを指定します。

ランタイムのヘルプを表示する

django-admin help

django-admin help を実行すると、使用方法の情報と、各アプリケーションが提供するコマンドのリストが表示されます。

django-admin help --commands を実行すると、利用可能な全てのコマンドの一覧が表示されます。

django-admin help <command> を実行すると、与えられたコマンドの説明と利用可能なオプションの一覧が表示されます。

アプリ名

多くのコマンドは「アプリ名」のリストを取ります。1つの「アプリ名」はモデルを含むパッケージのベースネーム (basename) となります。たとえば、INSTALLED_APPS が文字列 'mysite.blog' を含む場合、アプリ名は blog になります。

バージョンを特定する

django-admin version

django-admin version を実行すると、現在の Django のバージョンが表示されます。

出力は、次のように PEP 440 で説明されたスキーマに従います。

1.4.dev17026
1.4a1
1.4

デバック出力を表示する

サポートされている場合に --verbosity を使うと、django-admin がコンソールに表示する通知とデバッグ情報の量を指定できます。

利用可能なコマンド

check

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

システムチェック フレームワーク を使用して、Django プロジェクト全体のよくある問題を検査します。

デフォルトでは、全てのアプリがチェックされます。アプリのサブセットをチェックするには、次のようにアプリのラベルの一覧を引数として渡します。

django-admin check auth admin myapp

--tag TAGS, -t TAGS

システムチェック フレームワークは、 タグでカテゴリ化された さまざまな種類のチェックを実行します。これらのタグを使用すると、特定のカテゴリ内のタグだけに実行するチェックを制限できます。たとえば、モデルと互換性のチェックだけを実行するには、次のコマンドを実行します。

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

--database DATABASE

データベースアクセスが必要なチェックを実行するには、次のようにデータベースを指定します。

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

デフォルトでは、これらのチェックは実行されません。

--list-tags

利用可能なタグを一覧します。

--deploy

デプロイメントの設定にだけ関係のある、いくつかの追加チェックを有効化します。

このオプションはローカルの開発環境で使えますが、ローカルの開発の設定モジュールは本番の設定の多くがないかもしれないため、おそらく DJANGO_SETTINGS_MODULE 環境変数を設定するか、--settings オプションを渡すことで、異なる設定モジュールを指定したくなるでしょう。

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

あるいは、(--settings を省略して) 正しい設定が使用されていることを検証するために、本番かステージングのデプロイメントで直接実行することも可能です。

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

0 以外のステータスでコマンドを終了させるメッセージレベルを指定します。デフォルトは ERROR です。

compilemessages

django-admin compilemessages

ビルトインの gettext サポートで使用できるように、makemessages が作成した .po ファイルを .mo ファイルにコンパイルします。詳しくは 国際化とローカライズ を参照してください。

--locale LOCALE, -l LOCALE

処理する locale を指定します。提供されなかった場合、すべてのロケールが処理されます。

--exclude EXCLUDE, -x EXCLUDE

処理から除外する locale を指定します。提供されなかった場合、どのロケールも除外されません。

--use-fuzzy, -f

fuzzy な翻訳 をコンパイルされたファイルに含めます

使用例:

django-admin compilemessages --locale=pt_BR
django-admin compilemessages --locale=pt_BR --locale=fr -f
django-admin compilemessages -l pt_BR
django-admin compilemessages -l pt_BR -l fr --use-fuzzy
django-admin compilemessages --exclude=pt_BR
django-admin compilemessages --exclude=pt_BR --exclude=fr
django-admin compilemessages -x pt_BR
django-admin compilemessages -x pt_BR -x fr

--ignore PATTERN, -i PATTERN

与えられた glob スタイルのパターンに一致するディレクトリを無視します。 何度も無視するためには複数回使用してください。

使用例:

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

createcachetable

django-admin createcachetable

設定ファイルからの情報を使用して、データベース キャッシュ バックエンドで使用するためのキャッシュテーブルを作成します。詳細な情報については、 Django のキャッシュフレームワーク を参照してください。

--database DATABASE

キャッシュテーブルを作成するデータベースを指定します。デフォルトは default です。

--dry-run

実行予定の SQL を、実際には実行せずに出力します。これにより、SQL をカスタマイズしたり、マイグレーション フレームワークを使用できます。

dbshell

django-admin dbshell

USER や PASSWORD などの設定で指定されたコネクション パラメータを使用して、ENGINE 設定で指定されたデータベースエンジン用のコマンドライン クライアントを実行します。

• PostgreSQL の場合、psql コマンドライン クライアントが実行されます。

• MySQL の場合、mysql コマンドライン クライアントが実行されます。

• SQLite の場合、sqlite3 コマンドライン クライアントが実行されます。

• Oracle の場合、sqlplus コマンドライン クライアントが実行されます。

このコマンドは、プログラム名 (psql、mysql、sqlite3、sqlplus) の呼び出しで正しい場所にあるプログラムが見つかるように PATH が設定されているを想定しています。プログラムの場所を手動で指定する方法はありません。

--database DATABASE

シェルをオープンするデータベースを指定します。デフォルトは default です。

-- ARGUMENTS

-- 区切り文字に続く引数は、ベースのコマンドライン クライアントに渡されます。たとえば、PostgreSQL では、次のように psql コマンドの -c フラグを使うことで、素の SQL クエリを直接実行できます。

Linux/macOS

$ django-admin dbshell -- -c 'select current_user'
 current_user
--------------
 postgres
(1 row)

Windows

...\> django-admin dbshell -- -c 'select current_user'
 current_user
--------------
 postgres
(1 row)

MySQL/MariaDB では、次のように mysql の -e フラグを使用すると実行できます。

Linux/macOS

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

Windows

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

注釈

DATABASES のデータベース設定の OPTIONS 部分で設定されたすべてのオプションがコマンドラインクライアントに渡されるわけではないことに注意してください。例えば、'isolation_level' などです。

diffsettings

django-admin diffsettings

現在の設定ファイルと Django のデフォルトの設定 (または他の --default で指定された設定ファイル) の違いを表示します。

デフォルトに現れない設定には "###" が続きます。たとえば、デフォルト設定が ROOT_URLCONF を定義していない場合、diffsettings の出力内の ROOT_URLCONF の後には "###" が表示されます

--all

Django のデフォルト値が設定されていたとしても、すべての設定を表示する。このような設定には、前に "###" という接頭辞が付きます。

--default MODULE

現在の設定の比較対象にする設定モジュール。空にすると、Django のデフォルトの設定と比較します。

--output {hash,unified}

出力フォーマットを指定します。指定可能な値は hash と unified です。hash はデフォルトのモードで、上に説明したような出力を表示します。unified は diff -u に似た出力を表示します。デフォルトの設定はマイナス記号が前に付き、その後にプラス記号が前についた変更された設定が続きます。

dumpdata

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

名前を指定したアプリケーションと関連するデータベースの中のすべてのデータを、標準出力にアウトプットします。

アプリケーション名が指定されなかった場合、インストールされたすべてのアプリケーションをダンプします。

dumpdata のアウトプットは loaddata に対するインプットして使用できます。

dumpdata の出力をファイルとして保存すると、 テスト の フィクスチャ や、 初期データ として活用できます。

dumpdata は、ダンプするレコードを選択するために、モデルのデフォルトのマネージャを使用することに注意してください。カスタム マネージャ をデフォルトのマネージャとして使用していて、利用できるレコードの一部をフィルタリングしている場合、必ずしもすべてのオブジェクトがダンプされるわけではありません。

--all, -a

レコードをダンプする際に、フィルタリングまたは変更される可能性があるカスタム マネージャーの代わりに、Django のベース マネージャを使用します。

--format FORMAT

出力のシリアライズフォーマットを指定します。デフォルトは JSON です。対応フォーマットは シリアライズフォーマット に一覧があります。

--indent INDENT

出力で使用するインデントのスペースの数を指定します。デフォルトは None で、全てのデータを1行で表示します。

--exclude EXCLUDE, -e EXCLUDE

(app_label.ModelName の形式で指定された) 特定のアプリケーションやモデルがダンプされるのを防ぎます。モデル名を指定した場合には、アプリケーション全体ではなく、そのモデルだけが除外されます。アプリケーション名とモデル名を混ぜることもできます。

複数のアプリケーションを除外したいときは、--exclude を複数回渡してください。

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

--database DATABASE

データをダンプするデータベースを指定します。デフォルトは default です。

--natural-foreign

natural_key() モデルメソッドを使用して、任意の外部キーと多対多リレーションを、メソッドを定義している種類のオブジェクトにシリアルライズします。contrib.auth の Permission オブジェクトや contrib.contenttypes の ContentType オブジェクトをダンプする場合、おそらくこのフラグを使う必要があります。このオプションと次のオプションの詳細については、ナチュラルキー のドキュメントを参照しください。

--natural-primary

このオブジェクトのシリアライズされたデータの主キーを省略します。これが省略できるのは、デシリアライズ時に計算できるためです。

--pks PRIMARY_KEYS

カンマで区切られた主キーのリストで指定されたオブジェクトだけを出力します。これは1つのモデルをダンプするときのみ有効です。デフォルトでは、モデルのすべてのレコードが出力されます。

--output OUTPUT, -o OUTPUT

シリアライズされたデータを書き込むファイルを指定します。デフォルトでは、データは標準出力に出力されます。

このオプションが設定されていて、 --verbosity が 0 (デフォルト) より大きい場合、ターミナルにプログレスバーが表示されます。

フィクスチャの圧縮

出力ファイルは、ファイル名の最後に対応する拡張子をつけることで、 bz2、gz、lzma、xz のいずれかの形式で圧縮できます。たとえば、データを圧縮された JSON ファイルとして出力するには、次のようにします：

django-admin dumpdata -o mydata.json.gz

flush

django-admin flush

データベースからすべてのデータを削除し、同期後のハンドラを再実行します。マイグレーションが適用されたテーブルはクリアされません。

空のデータベースから始めて、すべてのマイグレーションを再実行したい場合は、代わりにデータベースを削除して再作成してから migrate を実行してください。

--noinput, --no-input

すべてのユーザープロンプトを表示しません。

--database DATABASE

フラッシュするデータベースを指定します。デフォルトは default です。

inspectdb

django-admin inspectdb [table [table ...]]

NAME 設定で指定されたデータベースのテーブルをイントロスペクトし、 Django モデルモジュール (models.py ファイル) を標準出力に出力します。

引数にテーブルやビューの名前を渡すことで、検査するテーブルやビューを選択できます。引数を指定しなかった場合、 --include-views オプションが使用された場合のみ、ビューのモデルが作成されます。PostgreSQL で --include-partitions オプションが使用された場合、パーティションテーブルのモデルが作成されます。

Django で使いたいレガシーデータベースがある場合に使ってください。このスクリプトはデータベースを検査し、各テーブルのモデルを作成します。

ご想像の通り、作成されたモデルはテーブルのすべてのフィールドに対して属性を持ちます。 inspectdb はフィールド名の出力において、いくつかの特殊なケースを持つことに注意してください：

• カラムの型をモデルのフィールド型にマッピングできない場合、inspectdb は TextField を使用し、生成されたモデルのフィールドの横に 'This field type is a guess.' という Python のコメントを挿入します。 認識されるフィールドは INSTALLED_APPS にリストされているアプリに依存します。たとえば、 django.contrib.postgres はいくつかの PostgreSQL 固有のフィールドタイプの認識を追加します。

• データベースのカラム名が Python の予約語 (pass', class', for' など) の場合、 inspectdb は属性名に '_field' を追加します。 例えば、テーブルに 'for' というカラムがある場合、生成されるモデルはフィールド 'for_field' を持ち、 db_column' 属性は 'for' に設定されます。その際、 inspectdb はフィールドの横に 'Field renamed because it was a Python reserved word." という Python コメントを挿入します。

この機能は、決定的なモデル生成としてではなく、ショートカットとして意図されています。 この機能を実行した後、生成されたモデルを自分で見て、カスタマイズしてください。特に、他のモデルを参照するモデルが適切に並ぶように、モデルの順序を並べ替える必要があるでしょう。

Django はモデルフィールドに default が指定されても、データベースのデフォルト値を作成しません。 同様に、データベースのデフォルト値はモデルフィールドのデフォルト値に変換されませんし、 inspectdb によって検出されることもありません。

デフォルトでは、 inspectdb は非管理モデルを作成します。 つまり、モデルの Meta クラスで managed = False を指定することで、 Django は各テーブルの作成、変更、削除を管理しないようになります。テーブルのライフサイクルを Django に管理させたい場合は、 managed オプションを True に変更する必要があります (あるいは、 True がデフォルト値なので削除してください)。

データベース固有の注意事項

Oracle

• --include-views が使用されている場合、モデルはマテリアライズドビューのために作成されます。

PostgreSQL

• モデルは外部テーブル用に作成されます。

• --include-views が使用されている場合、モデルはマテリアライズドビューのために作成されます。

• --include-partitions が使用されている場合、モデルはパーティションテーブルに対して作成されます。

--database DATABASE

イントロスペクトするデータベースを指定します。デフォルトは default です。

--include-partitions

このオプションを指定すると、パーティション用のモデルも作成されます。

PostgreSQL 向けのサポートのみが実装されています。

--include-views

このオプションを指定すると、データベースビュー用のモデルも作成されます。

loaddata

django-admin loaddata fixture [fixture ...]

指定された フィクスチャ の内容を検索してデータベースにロードします。

--database DATABASE

データを読み込むデータベースを指定します。デフォルトは default です。

--ignorenonexistent, -i

フィクスチャが最初に生成されてから削除された可能性のあるフィールドやモデルを無視します。

--app APP_LABEL

すべてのアプリでフィクスチャを探すのではなく、一つのアプリでフィクスチャを探すように指定します。

--format FORMAT

stdin から読み込む フィクスチャの シリアライズフォーマット (json や xml など) を指定します。

--exclude EXCLUDE, -e EXCLUDE

(app_label または app_label.ModelName の形で) 指定されたアプリケーションやモデルからのフィクスチャの読み込みを除外します。複数のアプリやモデルを除外するには、このオプションを複数回使います。

stdin からフィクスチャを読み込む

sys.stdin から入力を読み込むには、フィクスチャ名としてハイフンを使用します。たとえば下記のようにします：

django-admin loaddata --format=json -

stdin から読み込む場合、 --format オプションで入力の シリアライズフォーマット (例 json や xml) を指定する必要があります。

stdin からの読み込みは、標準入出力をリダイレクトするのに便利です。たとえば：

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

dumpdata コマンドは loaddata の入力を生成するために使用できます。

参考

フィクスチャの詳細については フィクスチャ (fixture) トピックを参照してください。

makemessages

django-admin makemessages

現在のディレクトリのソースツリー全体を走査し、翻訳が必要な文字列をすべて取り出します。conf/locale ディレクトリ (Django ツリーの場合) か locale ディレクトリ (プロジェクトとアプリケーションの場合) にメッセージファイルを作成 (または更新) します。メッセージファイルを変更した後は、組み込みの gettext サポートを使うために compilemessages でコンパイルする必要があります。詳しくは 国際化のドキュメント を参照してください。

このコマンドは設定を必要としません。しかし、設定が構成されていない場合、コマンドは MEDIA_ROOT と STATIC_ROOT ディレクトリを無視したり、 LOCALE_PATHS をインクルードしたりすることはできません。

--all, -a

利用可能な全ての言語に対してメッセージファイルを更新します。

--extension EXTENSIONS, -e EXTENSIONS

検査するファイル拡張子のリストを指定します (デフォルト: html、txt、py、 js (--domain が djangojs の場合)。

使用例:

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

複数の拡張子はカンマで区切るか、-e または --extension を複数回使用してください：

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

--locale LOCALE, -l LOCALE

処理する場所 (locale) を指定します。

--exclude EXCLUDE, -x EXCLUDE

処理から除外する locale を指定します。提供されなかった場合、どのロケールも除外されません。

使用例:

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

メッセージファイルのドメインを指定します。サポートされているオプションは以下の通りです:

• *.py、*.html、*.txt ファイルすべてに対して django (デフォルト)

• *.js ファイルに対して djangojs

--symlinks, -s

新しい翻訳文字列を探すときに、ディレクトリへのシンボリックリンクをたどります。

使用例:

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

--ignore PATTERN, -i PATTERN

与えられた glob スタイルのパターンに一致するファイルやディレクトリを無視します。 何度も無視するためには複数回使用してください。

次のパターンはデフォルトで使われます: 'CVS'、'.*'、'*~'、'*.pyc'。

使用例:

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

--no-default-ignore

--ignore のデフォルト値を無効化します。

--no-wrap

言語ファイル内で、長いメッセージ行の複数行への分割を無効化します。

--no-location

言語ファイル内に '#: filename:line' コメント行を書き込むのを抑制します。このオプションを使うと、技術的な翻訳者がそれぞれのメッセージの文脈を理解することが難しくなります。

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

言語ファイル中のコメント行 #: filename:line をコントロールします。オプションは下記です：

• full (省略時のデフォルト): ファイル名と行番号の両方を含む行を表示します。

• file: 行番号は省略されます。

• never: 行の出力が抑制されます (--no-location と同じ)。

gettext 0.19 以降が必要です。

--no-obsolete

廃止されたメッセージ文字列を .po ファイルから削除します。

--keep-pot

.po ファイルが作成される前に生成される一時的な .pot ファイルを削除しないようにします。最終的な言語ファイルが生成されるのを妨げるようなエラーをデバッグするために有用です。

参考

makemessages が xgettext に渡すキーワードをカスタマイズする方法を知りたい場合は、makemessages コマンドをカスタマイズする を参照してください。

makemigrations

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

検出されたモデルの変更に基づいて、新しいマイグレーションを作成します。マイグレーションおよびそのアプリとの関係は、詳しくは マイグレーションのドキュメント で説明しています。

1つ以上のアプリ名を引数として与えると、作成するマイグレーションを、指定されたアプリとそれに必要な依存関係 (たとえば、外部キーで繋がれた他のテーブルなど) に限定されます。

マイグレーションを migrations ディレクトリが存在しないアプリに追加するには、makemigrations にアプリの app_label を付けて実行します。

--noinput, --no-input

すべてのユーザープロンプトを抑制します。もし、抑制されたプロンプトが自動的に解決できなかった場合は、エラーコード 3 で終了します。

--empty

手動で編集するために、指定されたアプリに対する空のマイグレーションを出力します。このオプションは詳しいユーザーのためのもので、マイグレーションのフォーマット、マイグレーション・オペレーション、およびマイグレーション間の依存関係について十分理解していない限り、使うべきではありません。

--dry-run

実際にマイグレーションをディスクには書き込まず、作成される予定のマイグレーションを表示します。このオプションを --verbosity 3 オプションと併用することで、書き込まれる予定のマイグレーションファイルの内容そのものを表示できます。

--merge

マイグレーションで発生するコンフリクトの修復を有効にする

--name NAME, -n NAME

生成されたマイグレーションに名前を付けることができます。名前は有効な Python 識別子 でなければなりません。

--no-header

Django のバージョンとタイムスタンプヘッダなしでマイグレーションファイルを生成します。

--check

マイグレーションを伴わないモデル変更が検出された場合に、 makemigrations を 0 以外のステータスで終了するようにします。これは --dry-run を意味します。

--scriptable

ログ出力と入力プロンプトを stderr に流し、生成されたマイグレーションファイルのパスのみを stdout に書き込みます。

--update

モデルの変更を最新のマイグレーションにマージし、その結果生じるオペレーションを最適化します。

更新されたマイグレーションは生成された名前を持ちます。以前の名前を保持するには、--name を使って設定してください。

migrate

django-admin migrate [app_label] [migration_name]

データベースの状態を、現在のモデルとマイグレーションのセットを基づいて同期します。マイグレーションおよびそのアプリとの関係については、詳しくは マイグレーションのドキュメント で説明しています。

このコマンドの動作は、次のように与えられた引数によって変化します。

• 引数なし: 全てのアプリが、それぞれが持つマイグレーションを全て実行します。

• <app_label>: 指定したアプリに最新のマイグレーションまで実行させます。依存関係によっては、他のアプリのマイグレーションも実行される場合もあります

• <app_label> <migrationname>: データベーススキーマを、指定した名前のマイグレーションが実行された状態になるようにします。指定したよりも後のマイグレーションは適用されません。指定されたより前のマイグレーションがすでに適用されていた場合など、指定の仕方によってはマイグレーションが実行できない場合があります。アプリに対するすべてのマイグレーションの適用をリセットするには、zero という名前を指定してください。指定したアプリ名で一意であれば、マイグレーション名のプレフィックス、例えば 0001 を使用できます。アプリに適用されたマイグレーションをすべて元に戻すには zero という名前を指定してください。

警告

マイグレーションの適用を取り消すと、<app_label> に関係なく、依存するマイグレーションもすべて取り消されます。どのマイグレーションが取り消されるかを調べるには --plan を使用してください。

--database DATABASE

マイグレートするデータベースを指定します。デフォルトは default です。

--fake

（上記のルールに従って）ターゲットのマイグレーションまでを適用されたものとしてマークしますが、データベーススキーマを変更するSQLを実際には実行しません。

これは上級ユーザが手動で変更を適用する場合に、現在のマイグレーション状態を直接操作することを想定しています。 --fake を使用すると、マイグレーションを正しく実行するためにマイグレーション状態テーブルを手動で回復する必要がある状態になる危険性があることに注意してください。

--fake-initial

マイグレーションに含まれる全ての CreateModel オペレーションで作成された全てのモデルの名前を持つデータベーステーブルが既に存在する場合、 Django がアプリの初期マイグレーションをスキップできるようにします。このオプションは、マイグレーションを使用する前のデータベースに対してマイグレーションを初めて実行するときに使用することを想定しています。しかし、このオプションは、テーブル名の一致以外のデータベーススキーマの一致をチェックしないので、既存のスキーマが初期マイグレーションに記録されているものと一致することを確信している場合のみ安全に使用できます。

--plan

指定された migrate コマンドに対して実行されるマイグレーション・オペレーションを表示します。

--run-syncdb

マイグレーションせずにアプリ用のテーブルを作成できるようにします。これは推奨されませんが、マイグレーションフレームワークは何百ものモデルがある大規模なプロジェクトでは遅すぎることがあります。

--noinput, --no-input

すべてのユーザープロンプトを表示しません。プロンプトの例は、古くなったコンテンツタイプの削除に関する質問です。

--check

適用されていないマイグレーションが検出された場合に、 migrate を 0 以外のステータスで終了するようにします。

--prune

存在しないマイグレーションを django_migrations テーブルから削除します。これはスカッシュしたマイグレーションによって置き換えられたマイグレーションファイルが削除された場合に便利です。詳細は マイグレーションのスカッシュ (Squash) を参照してください。

optimizemigration

django-admin optimizemigration app_label migration_name

指定されたマイグレーション・オペレーションを最適化し、既存のファイルを上書きします。マイグレーションに手動でコピーしなければならない関数が含まれている場合、このコマンドは _optimized で終わる新しいマイグレーションファイルを作成し、指定されたマイグレーションを置き換えます。

--check

マイグレーションを最適化できる場合に、 optimizemigration を 0 以外のステータスで終了するようにします。

runserver

django-admin runserver [addrport]

ローカルマシンで軽量の開発用ウェブサーバを起動します。デフォルトでは、IPアドレス 127.0.0.1 のポート 8000 で動作します。IPアドレスとポート番号を明示的に渡すこともできます。

このスクリプトを通常の権限を持つユーザ（推奨）で実行した場合、小さいポート番号のポートを起動するためのアクセス権がない可能性があります。小さいポート番号はスーパーユーザ（root）のために予約されています。

このサーバーは WSGI_APPLICATION 設定で指定された WSGI アプリケーションオブジェクトを使用します。

警告

このサーバーは本番環境で使用しないでください。

この軽量な開発用サーバーは、セキュリティ監査やパフォーマンステストを受けていないため、本番環境には不適切です。このサーバーを本番環境で使用できるようにすることは、Django のスコープ外です。

開発サーバーは必要に応じてリクエストごとにPythonコードを自動的にリロードします。コード変更の効果を得るためにサーバーを再起動する必要はありません。しかしながら、ファイルの追加のようないくつかの行動は再起動をトリガーしません、このような場合はサーバーを再起動する必要があります。

Linux や MacOS を使用していて、 pywatchman と Watchman サービスの両方をインストールしている場合、カーネルシグナルがサーバーの自動再ロードに使用されます(毎秒ファイルの変更タイムスタンプをポーリングするのではなく)。これにより、大規模なプロジェクトでのパフォーマンスが改善され、コード変更後の 応答時間が短縮され、変更検出がより強固になり、消費電力が削減されます。Django は pywatchman 1.2.0 以降をサポートしています。

巨大なディレクトリに多くのファイルが含まれる場合、パフォーマンスの問題を引き起こす可能性があります。

node_modules のような大きな非 Python ディレクトリを含むプロジェクトで Watchman を使う場合、最適なパフォーマンスのためにこのディレクトリを無視することをお勧めします。この方法については watchman documentation を参照してください。

Watchman のタイムアウト

DJANGO_WATCHMAN_TIMEOUT

Watchman クライアントのデフォルトのタイムアウトは 5 秒です。これを変更するには DJANGO_WATCHMAN_TIMEOUT 環境変数を設定します。

サーバを起動したとき、そしてサーバ起動中に Python コードを変更するたびに、システムチェックフレームワークが Django プロジェクト全体に一般的なエラーがないかチェックします (check コマンドを参照してください)。エラーが見つかった場合、標準出力に出力されます。システムチェックの実行をスキップするには --skip-checks オプションを使います。

django-admin runserver を複数回実行することで、異なるポート上であれば、好きなだけ並列でサーバーを実行できます。

デフォルトの IP アドレス 127.0.0.1 は、同じネットワーク上の他のマシンからはアクセスできないことに注意してください。開発用サーバーを他のマシンから見られるようにするには、ネットワーク上の自分のローカル IP アドレス (例 192.168.2.1) または 0 (0.0.0.0 のショートカット)、 0.0.0.0 、または :: (IPv6を有効にした場合) を使用します。

ブラケットで囲んだ IPv6 アドレス (例 [200a::1]:8000) も使用できます。その場合は、IPv6 のサポートが自動的に有効になります。

ホスト名には ASCII 文字のみからなる文字列も使用できます。

staticfiles contrib アプリが有効になっている場合 (新しいプロジェクトのデフォルト)、 runserver コマンドは独自の runserver コマンドで上書きされます。

サーバの各リクエストとレスポンスのログは django.server ロガーに送られます。

--noreload

自動リローダを無効にします。これは、もし特定の Python モジュールが既にメモリに読み込まれている場合、サーバの実行中に行った Python コードの変更は 反映 されないことを意味します。

--nothreading

開発サーバーでのスレッドの使用を無効にします。デフォルトではサーバーはマルチスレッドです。

--ipv6, -6

開発用サーバーで IPv6 を使用します。これにより、デフォルトの IP アドレスが 127.0.0.1 から ::1 に変わります。

DJANGO_RUNSERVER_HIDE_WARNING

New in Django 5.2.

デフォルトでは、runserver は本番環境には適さないという警告がコンソールに表示されます。

WARNING: This is a development server. Do not use it in a production setting. Use a production WSGI or ASGI server instead.
For more information on production servers see: https://docs.djangoproject.com/en/|version|/howto/deployment/

警告を非表示にする場合、この環境変数を "true" に設定します。

異なるポートとアドレスを使用する場合の引数例

IP アドレス 127.0.0.1 上でポート 8000 を使用する場合:

django-admin runserver

IP アドレス 1.2.3.4 上でポート 8000 を使用する場合:

django-admin runserver 1.2.3.4:8000

IP アドレス 127.0.0.1 上でポート 7000 を使用する場合:

django-admin runserver 7000

IP アドレス 1.2.3.4 上でポート 7000 を使用する場合:

django-admin runserver 1.2.3.4:7000

IPv6 アドレス ::1 上でポート 8000 を使用する場合:

django-admin runserver -6

IPv6 アドレス ::1 上でポート 7000 を使用する場合:

django-admin runserver -6 7000

IPv6 アドレス 2001:0db8:1234:5678::9 上でポート 7000 を使用する場合:

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

IPv4 アドレスのホスト localhost 上でポート 8000 を使用する場合:

django-admin runserver localhost:8000

IPv6 アドレスのホスト localhost 上でポート 8000 を使用する場合:

django-admin runserver -6 localhost:8000

開発用サーバーで静的 (static) ファイルを配信する

デフォルトでは、開発サーバはサイトの静的ファイル (CSS ファイルや画像、 MEDIA_URL 以下にあるものなど) を配信しません。Django が静的メディアを配信するように設定したい場合は、 静的ファイル (画像、JavaScript、CSS など) を管理する を参照してください。

開発中に ASGI サーバーを使う

Django の runserver コマンドは WSGI サーバーを提供します。ASGI で実行するには、 ASGI サーバー を使う必要があります。Django Daphne プロジェクトは、 runserver との統合 を提供しています。

sendtestemail

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

（Django によるメール送信が動作していることを確認するために）指定した受信者にテストメールを送信します。たとえば以下のようにします：

django-admin sendtestemail [e-mail] [e-mail]

いくつかのオプションがあるので、次のようにそれらを任意に組み合わせて使用できます。

--managers

mail_managers() を使用して MANAGERS で指定されたメールアドレスにメールします。

--admins

mail_admins() を使用して ADMINS で指定されたメールアドレスにメールします。

shell

django-admin shell

Python のインタラクティブ・インタープリタを開始します。

インストール済みアプリのすべてのモデルは、シェル環境に自動的にインポートされます。 INSTALLED_APPS において先に記述されたアプリのモデルが優先されます。 --verbosity を 2 以上に設定すると、自動的にインポートされたオブジェクトが一覧表示されます。自動インポートを完全に無効にしたい場合は、 --no-imports フラグを使用してください。

自動インポートを追加または削除するには、 挙動をカスタマイズする ガイドを参照してください。

Changed in Django 5.2:

自動モデルインポートが追加されました。

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

使用するシェルを指定します。デフォルトでは、Django はインストールされている場合には IPython または bpython を使用します。両方インストールされている場合には、次のようにして使いたいシェルを指定してください。

IPython:

django-admin shell -i ipython

bpython:

django-admin shell -i bpython

"リッチな" シェルをインストールしているが、"プレーン" な Python インタプリタを強制的に使いたい場合は、インターフェイス名として python を次のように使用します：

django-admin shell -i python

--no-startup

"プレーン" Python インタプリタのスタートアップスクリプトを読み込まないようにします。デフォルトでは PYTHONSTARTUP 環境変数か ~/.pythonrc.py スクリプトが指すスクリプトが読み込まれます。

--no-imports

New in Django 5.2.

INSTALLED_APPS からモデルの自動インポートを無効にします。

--command COMMAND, -c COMMAND

以下のように、コマンドを文字列で渡して、Django として実行できます：

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

標準入力にコードを渡して実行することもできます。たとえば：

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

Windowsでは、そのプラットフォームでの select.select() の実装制限に応じて REPL が出力されます。

showmigrations

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

プロジェクト内のすべてのマイグレーションを表示します。2つの形式から選択できます：

--list, -l

Django が知っている全てのアプリ、各アプリで利用可能なマイグレーション、各マイグレーションが適用されているかどうか（マイグレーション名の横に [X] と表示されます）を一覧表示します。また、 --verbosity が 2 以上の場合、適用された日時も表示されます。

マイグレーションのないアプリもリストアップされますが、その下に (no migrations) と表示されます。

これはデフォルトの出力形式です。

--plan, -p

Django が適用するマイグレーションの計画を表示します。 list と同様に、適用されたマイグレーションは [X] でマークされます。また、 --verbosity が 2 以上の場合、マイグレーションの全ての依存関係も表示されます。

app_label 引数によって出力は制限されますが、提供されたアプリの依存関係も含めることができます。

--database DATABASE

検査するデータベースを指定します。デフォルトは default です。

sqlflush

django-admin sqlflush

flush コマンドで実行される SQL 文を表示します。

--database DATABASE

SQLを表示するデータベースを指定します。デフォルトは default です。

sqlmigrate

django-admin sqlmigrate app_label migration_name

指定された名前のマイグレーション用の SQL を出力します。これは、制約名の解決に使用するアクティブなデータベース接続を必要とします。つまり、後で適用したいデータベースのコピーに対して SQL を生成する必要があります。

sqlmigrate は出力に色をつけないことに注意してください。

--backwards

マイグレーションの適用を取り消すSQLを生成します。デフォルトでは、マイグレーションを順方向に実行するための SQL が生成されます。

--database DATABASE

SQL を生成するデータベースを指定します。デフォルトは default です。

sqlsequencereset

django-admin sqlsequencereset app_label [app_label ...]

指定されたアプリ名のシーケンスをリセットする SQL 文を出力します。

シーケンスは、自動的にインクリメントされるフィールドの次に利用可能な番号を追跡するために、いくつかのデータベースエンジンで使用されるインデックスです。

このコマンドを使用して、シーケンスが自動的にインクリメントされたフィールドデータと同期していないケースを修正するSQLを生成できます。

--database DATABASE

SQLを表示するデータベースを指定します。デフォルトは default です。

squashmigrations

django-admin squashmigrations app_label [start_migration_name] migration_name

migration_name までの app_label のマイグレーションを、可能であればより少ないマイグレーションにスカッシュします。スカッシュされたマイグレーションは、スカッシュされていないマイグレーションと安全に共存できます。詳しくは マイグレーションのスカッシュ (Squash) を参照してください。

start_migration_name を指定すると、 Django はこのマイグレーションから始まり、このマイグレーションを含むマイグレーションだけを取り込みます。これは RunPython と django.db.migrations.operations.RunSQL マイグレーション・オペレーションのスカッシュ制限を緩和するのに役立ちます。

--no-optimize

スカッシュされたマイグレーションを生成する際に、オプティマイザを無効にします。デフォルトでは、 Django はマイグレーションする際の処理を最適化し、結果のファイルサイズを小さくしようとします。この処理が失敗したり、正しくないマイグレーションを作成したりする場合は、このオプションを使ってください。最適化は安全であることを意図しているので、その動作について Django バグレポートを提出してください。

--noinput, --no-input

すべてのユーザープロンプトを表示しません。

--squashed-name SQUASHED_NAME

スカッシュされたマイグレーションの名前を設定します。省略した場合は、最初と最後のマイグレーションの間に _squashed_ を加えた名前になります。

--no-header

Django のバージョンとタイムスタンプのヘッダなしで、スカッシュしたマイグレーションファイルを生成します。

startapp

django-admin startapp name [directory]

指定されたアプリ名の Django アプリディレクトリ構造を、カレントディレクトリか、指定された保存先に作成します。

デフォルトでは、新しいディレクトリ には models.py ファイルと他のアプリテンプレートファイルが含まれます。アプリ名だけが与えられた場合、アプリディレクトリは現在の作業ディレクトリに作成されます。

オプションで保存先を指定すると、 Django は新しいディレクトリを作成するのではなく、既存のディレクトリを使用します。現在の作業ディレクトリを表すには "." を使用してください。

例:

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

--template TEMPLATE

カスタムアプリテンプレートファイルを含むディレクトリへのパス、または圧縮されていないアーカイブ (.tar) や圧縮されたアーカイブ (.tar.gz, .tar.bz2, .tar.xz, .tar.lzma, .tgz, .tbz2, .txz, .tlz, .zip) 内のアプリテンプレートファイルを含むパスを指定します。

たとえば、myapp アプリを作成するときに、指定されたディレクトリのアプリテンプレートを探すには以下のようにします：

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

Djangoは、アプリテンプレートファイルを含む圧縮アーカイブへのURL (http、https、ftp) も受け付けることができ、それらをダウンロードしてリアルタイムで展開します。

たとえば、GitHub の zip ファイルとしてリポジトリを公開する機能を使えば、次のような URL を使うことができます：

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

警告

--template で指定されたテンプレートはそのまま使用されます。悪意のある、あるいは不適切に作成されたテンプレートは、セキュリティ上の脆弱性や意図しない動作を引き起こす可能性があります。さらに、圧縮アーカイブは展開時に過剰なリソースを消費し、クラッシュやフリーズを引き起こすおそれがあります。

テンプレートの内容は、使用する前に慎重に検査されるべきです。

--extension EXTENSIONS, -e EXTENSIONS

アプリテンプレート内のどの拡張子をテンプレートエンジンでレンダリングするかを指定します。デフォルトは py です。

--name FILES, -n FILES

(--extension にマッチするものに加えて) アプリテンプレート内のどのファイルをテンプレートエンジンでレンダリングするかを指定します。デフォルトは空のリストです。

--exclude DIRECTORIES, -x DIRECTORIES

.git と __pycache__ に加えて、アプリテンプレート内のどのディレクトリを除外するかを指定します。このオプションを指定しない場合、__pycache__ という名前のディレクトリや、. で始まるディレクトリは除外されます。

マッチする全てのファイルに使用される テンプレートコンテキスト は以下の通りです：

• startapp コマンドに渡されたオプション (コマンドでサポートされているオプションに限る)

• app_name -- コマンドに渡されたアプリ名

• app_directory -- 新規作成されたアプリのフルパス

• camel_case_app_name -- キャメルケース形式のアプリ名

• docs_version -- ドキュメントのバージョン: 'dev' または 1.x'

• django_version -- Django のバージョン、例えば '2.0.3' 。

警告

アプリのテンプレートファイルが Django テンプレートエンジンでレンダリングされるとき (デフォルトではすべての *.py ファイル)、Django は含まれるすべての不明なテンプレート変数も置き換えます。たとえば、 Python ファイルの 1 つに、テンプレートレンダリングに関連する特定の機能を説明する docstring が含まれていた場合、間違った結果を生むかもしれません。

この問題を回避するために、テンプレートタグ templatetag を使ってテンプレートの構文の様々な部分を「エスケープ」することができます。

さらに、パッケージングシステムが無効な *.py ファイルをバイトコンパイルしようとするのを防ぐと同時に、 Django テンプレート言語構文を含む Python テンプレートファイルを許可するために、 .py-tpl で終わるテンプレートファイルは .py にリネームされます。

警告

カスタムアプリ（またはプロジェクト）テンプレートのコンテンツは、使用前に必ず監査されるべきです。 これらのテンプレートは、プロジェクトの一部となるコードを定義しており、これらのコードは、インストールしたアプリや自分で書いたコードと同じくらい信頼されることを意味します。さらに、テンプレートをレンダリングすることは、事実上、提供されたコードを管理コマンドへの入力として実行することにすらなります。Django のテンプレート言語は、システムへの広いアクセスを提供する可能性がありますので、使うカスタムテンプレートが信頼に値するものであることを確認してくだ さい。

startproject

django-admin startproject name [directory]

指定されたプロジェクト名の Django プロジェクトディレクトリ構造を、カレントディレクトリか指定された保存先に作成します。

デフォルトでは、 新しいディレクトリ には manage.py とプロジェクトパッケージ (settings.py と他のファイルを含む) があります。

プロジェクト名だけを指定した場合、プロジェクトディレクトリとプロジェクトパッケージは <projectname> という名前になり、プロジェクトディレクトリは現在の作業ディレクトリに作成されます。

オプションで保存先を指定すると、 Django はその既存のディレクトリをプロジェクトディレクトリとして使用し、 manage.py とその中にプロジェクトパッケージを作成します。現在の作業ディレクトリを表すには "." を使用してください。

例:

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

--template TEMPLATE

ディレクトリ、ファイルパス、またはカスタムプロジェクトテンプレートの URL を指定します。使用例については startapp --template のドキュメントを参照してください。なお、 startapp テンプレートに関して説明されている セキュリティ上の考慮事項 が同様に適用されます。すなわち、悪意のある、あるいは不適切に作成されたテンプレートは脆弱性をもたらしたり、過剰なリソースを消費する可能性があり、テンプレートは使用前に慎重に検査されるべきです。

--extension EXTENSIONS, -e EXTENSIONS

プロジェクトテンプレート内のどの拡張子をテンプレートエンジンでレンダリングするかを指定します。デフォルトは py です。

--name FILES, -n FILES

(--extension にマッチするものに加えて) プロジェクトテンプレート内のどのファイルをテンプレートエンジンでレンダリングするかを指定します。デフォルトは空のリストです。

--exclude DIRECTORIES, -x DIRECTORIES

.git と __pycache__ に加えて、プロジェクトテンプレート内のどのディレクトリを除外するかを指定します。このオプションを指定しない場合、__pycache__ という名前のディレクトリや、. で始まるディレクトリは除外されます。

使用される テンプレートコンテキスト は以下の通りです：

• startproject コマンドに渡されたオプション (コマンドでサポートされているオプションに限る)

• project_name -- コマンドに渡されたプロジェクト名

• project_directory -- 新規作成されたプロジェクトのフルパス

• secret_key -- SECRET_KEY 設定用のランダムなキー。

• docs_version -- ドキュメントのバージョン: 'dev' または 1.x'

• django_version -- Django のバージョン、例えば '2.0.3' 。

startapp で説明した レンダリングに関する警告 と 信頼されたコードに関する警告 も参照してください。

test

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

インストールされている全てのアプリのテストを実行します。詳しくは Django におけるテスト を参照してください。

--failfast

テストが失敗したら直ちにテストの実行を停止し、失敗を報告します。

--testrunner TESTRUNNER

テストの実行に使われるテストランナークラスを制御します。この値は TEST_RUNNER 設定によって提供される値を上書きします。

--noinput, --no-input

すべてのユーザープロンプトを表示しません。典型的なプロンプトは、既存のテストデータベースの削除に関する警告です。

テストランナーのオプション

test コマンドは指定された --testrunner の代わりにオプションを受け取ります。これらはデフォルトのテストランナーである DiscoverRunner のオプションです。

--keepdb

テスト実行の間、テストデータベースを保持します。これには、作成と破棄の両方のアクションを省略できるという利点があり、 特に大規模なテストスイートにおけるテストの実行時間を大幅に短縮できます。テストデータベースが存在しない場合は、最初の実行時に作成され、それ以降の実行時に保存されます。MIGRATE テスト設定が False でない限り、テストスイートを実行する前に、未適用のマイグレーションもテストデータベースに適用されます。

--shuffle [SEED]

テストを実行する前に、テストの順番をランダムにします。これは、適切に分離されていないテストの検出に役立ちます。このオプションで生成されるテストの順番は、 与えられた整数シードの決定論的な関数です。シードが渡されない場合は、ランダムにシードが選ばれてコンソールに出力されます。特定のテスト順序を繰り返すには、シードを渡します。このオプションで生成されるテスト順序は Django の テスト順序における保証 を保持します。また、テストはテストケースクラスごとにグループ化されます。

シャッフルされた順序は、分離の問題を絞り込む際に有用な特別な一貫性を持っています。つまり、シードを指定してテストのサブセットを実行する場合、新しい順序はより小さなセットに制限されつつ、元のシャッフル順序を維持します。同様に、シードを同じに保ちながらテストを追加すると、元のテストの順序は新しい順序でも同じままです。

--reverse, -r

テストケースを逆の実行順序で並べ替えます。これは適切に分離されていないテストの副作用をデバッグする際に役立つかもしれません。 テストクラス によるグループ化は、このオプションを使用しても保持されます。 --shuffle と組み合わせて使用することで、特定のシードの順番を逆にできます。

--debug-mode

テストを実行する前に DEBUG 設定を True に設定します。これはテストの失敗のトラブルシューティングに役立ちます。

--debug-sql, -d

失敗したテストの SQL ロギング を有効にします。もし --verbosity が 2 なら、パスしたテストのクエリも出力されます。

--parallel [N]

DJANGO_TEST_PROCESSES

別々の並列プロセスでテストを実行します。現代のプロセッサは複数のコアを備えているため、これによってテストの実行速度を大幅に向上させることができます。

値を指定せずに --parallel を使用した場合、または値 auto を指定した場合、 multiprocessing.cpu_count() に従って各コアに 1 つのテストプロセスを実行します。これをオーバーライドするには、必要なプロセス数、たとえば --parallel 4 を渡すか、 DJANGO_TEST_PROCESSES 環境変数を設定します。

Django はテストケース (unittest.TestCase サブクラス) をサブプロセスに分散します。設定されたプロセス数よりもテストケースクラスの数が少ない場合、 Django はそれに応じてプロセス数を減らします。

各プロセスごとに個別のデータベースを持つため、異なるテストケースクラスが同じリソースにアクセスしないように注意が必要です。たとえば、複数のテストケースクラスがファイルシステムにアクセスするような場合には、各テストケースクラスごとに個別に一時ディレクトリを作成するようにしてください。

注釈

並列で実行できないテストクラスがある場合は、 SerializeMixin を使って逐次的に実行できます。 テストクラスの逐次実行を強制する を参照してください。

このオプションはトレースバックを正しく表示するために、サードパーティの tblib パッケージが必要です：

$ python -m pip install tblib

この機能はWindowsでは使用できません。Oracleデータベースのバックエンドでも動作しません。

テストのデバッグ中に pdb を使用したい場合は、並列実行を無効にする必要があります (--parallel=1) 。そうしないと bdb.BdbQuit のようなメッセージが表示されます。

警告

テストの並列化が有効で、テストが失敗した場合、 Django は例外のトレースバックを表示できないかもしれません。これはデバッグを困難にします。この問題に遭遇した場合は、並列化せずに該当するテストを実行して、失敗のトレースバックを確認してください。

これは既知の制限です。これは、プロセス間でオブジェクトを交換するためにオブジェクトをシリアライズする必要があることから生じます。詳しくは What can be pickled and unpickled? を参照してください。

--tag TAGS

指定したタグ でマークされたテストのみを実行します。test --exclude-tag と組み合わせて複数回指定できます。

ロードに失敗したテストは常にマッチしたとみなされます。

--exclude-tag EXCLUDE_TAGS

指定したタグ でマークされたテストを除外します。test --tag と組み合わせて複数回指定できます。

-k TEST_NAME_PATTERNS

unittest の -k オプション と同じように、テスト名のパターンにマッチするテストメソッドとクラスを実行します。複数回指定できます。

--pdb

テストのエラーや失敗のたびに pdb デバッガを起動します。インストールされている場合は、代わりに ipdb が使用されます。

--buffer, -b

unittest の --buffer オプション と同じように、テストに合格した出力 (stdout と stderr) を破棄します。

--no-faulthandler

Django はテストの開始時に faulthandler.enable() を自動的に呼び出します。これにより、インタプリタがクラッシュした場合にトレースバックを表示します。この動作を無効にするには --no-faulthandler を渡してください。

--timing

データベースのセットアップや総実行時間などのタイミングを出力します。

--durations N

最も遅い N 個のテストケースを表示します（N=0 の場合はすべて）。

Python 3.12 以降が必要です

この機能は Python 3.12 以降でのみ利用可能です。

testserver

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

(runserver のように) 与えられたフィクスチャのデータを使って Django 開発サーバを起動します。

たとえばこのコマンドは、：

django-admin testserver mydata.json

... 以下のステップを実行します：

1. test データベース で説明されているように、テスト用データベースを作成します。

2. 与えられたフィクスチャからフィクスチャデータをテストデータベースに投入します。(フィクスチャの詳細については、上記の loaddata のドキュメントを参照してください)。

3. Django 開発サーバを実行します (runserver のように)。本番用データベースの代わりに、新しく作成したテスト用データベースを指定します。

これはいろいろな面で便利です：

• ユニットテスト を書くとき、フィクスチャデータを使ってビューがどのように動作するか、 testserver を使ってウェブブラウザでビューと手動でやりとりできます。

• Django アプリケーションを開発していて、対話したいデータベースの "まっさらな" コピーがあるとします。データベースを フィクスチャ にダンプし (上で説明した dumpdata コマンドを使います)、そのデータを使って testserver で Web アプリケーションを実行します。この方法では、どんなデータの変更もテスト用のデータベースに対してだけ行われるため、柔軟にデータを変更できます。

このサーバは Python のソースコードの変更を (runserver のように) 自動的に検出することは しない ことに注意してください。しかし、テンプレートの変更は検出します。

--addrport ADDRPORT

デフォルトの 127.0.0.1:8000 とは異なるポート、または IP アドレスとポートを指定します。この値は runserver コマンドの引数と全く同じフォーマットで、全く同じ機能を果たします。

例:

ポート7000で fixture1 と fixture2 を使ってテストサーバを動かすには、以下のようにします：

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

（上の2つは等価です。オプションがフィクスチャの引数の前でも後でも問題ないことを示すために、この2つを紹介しています）

1.2.3.4:7000 で test フィクスチャを使って実行するには、下記のようにします：

django-admin testserver --addrport 1.2.3.4:7000 test

--noinput, --no-input

すべてのユーザープロンプトを表示しません。典型的なプロンプトは、既存のテストデータベースの削除に関する警告です。

アプリケーションが提供するコマンド

いくつかのコマンドは、それを 実装した django.contrib アプリケーションが 有効に なっていないと利用できません。この節では、それらをアプリケーションごとに分類して説明します。

django.contrib.auth

changepassword

django-admin changepassword [<username>]

このコマンドは Django の 認証システム (django.contrib.auth) がインストールされている場合のみ利用できます。

ユーザのパスワードを変更できます。指定されたユーザの新しいパスワードを2回入力するよう求められます。入力が同じであれば、これが直ちに新しいパスワードになります。ユーザを指定しなかった場合、コマンドはユーザ名が現在のユーザと一致するパスワードを変更しようとします。

--database DATABASE

ユーザーをクエリするデータベースを指定します。デフォルトは default です。

使用例:

django-admin changepassword ringo

createsuperuser

django-admin createsuperuser

DJANGO_SUPERUSER_PASSWORD

このコマンドは Django の 認証システム (django.contrib.auth) がインストールされている場合のみ利用できます。

superuser アカウント (すべての権限を持ったユーザー) を作成します。このコマンドは、最初に superuser アカウントを作成する場合や、サイトの superuser アカウントをプログラムから自動生成する必要がある場合に便利です。

対話的に実行すると、このコマンドは新しいスーパーユーザアカウントのパスワードを要求します。非対話的に実行する場合、 DJANGO_SUPERUSER_PASSWORD 環境変数を設定することでパスワードを設定できます。そうでない場合、パスワードは設定されず、スーパーユーザーアカウントはパスワードが手動で設定されるまでログインできません。

非インタラクティブモードでは、 USERNAME_FIELD と必須フィールド (REQUIRED_FIELDS にリストされています) はコマンドライン引数で上書きされない限り、環境変数 DJANGO_SUPERUSER_<uppercase_field_name> にフォールバックします。例えば、 email フィールドを指定するには、環境変数 DJANGO_SUPERUSER_EMAIL を使用します。

--noinput, --no-input

すべてのユーザープロンプトを表示しません。もし、抑制されたプロンプトが自動的に解決できなかった場合は、エラーコード 1 で終了します。

--username USERNAME

--email EMAIL

新しいアカウントのユーザー名とメールアドレスはコマンドラインの --username と --email 引数で指定できます。これらのどちらかが与えられない場合、 createsuperuser は対話的に実行する際にその入力を要求します。

--database DATABASE

スーパーユーザ・オブジェクトを保存するデータベースを指定します。

データの入力とバリデーションをカスタマイズしたい場合は、管理コマンドをサブクラス化して get_input_data() をオーバーライドします。既存の実装やメソッドのパラメータの詳細についてはソースコードを参照してください。たとえば、REQUIRED_FIELDS に ForeignKey があり、既存のインスタンスの主キーを入力する代わりにインスタンスを作成できるようにしたい場合に便利です。

django.contrib.contenttypes

remove_stale_contenttypes

django-admin remove_stale_contenttypes

このコマンドは Django の contenttypes アプリ (django.contrib.contenttypes) がインストールされている場合のみ利用できます。

（削除されたモデルの）古くなったコンテンツタイプをデータベースから削除します。削除されたコンテンツタイプに依存しているオブジェクトも削除されます。削除されたオブジェクトのリストが表示された後、削除を続行できます。

--database DATABASE

使用するデータベースを指定します。デフォルトは default です。

--include-stale-apps

INSTALLED_APPS から削除された、以前にインストールされたアプリのものを含む、古くなったコンテンツタイプを削除します。デフォルトは False です。

django.contrib.gis

ogrinspect

このコマンドは、GeoDjango (django.contrib.gis) がインストールされている場合のみ使用できます。

GeoDjango のドキュメントの description を参照してください。

django.contrib.sessions

clearsessions

django-admin clearsessions

cron job に設定したり、直接実行することで、期限切れのセッションを削除できます。

django.contrib.staticfiles

collectstatic

このコマンドは static files アプリケーション (django.contrib.staticfiles) がインストールされている場合のみ使用できます。

staticfiles ドキュメントの description を参照してください。

findstatic

このコマンドは static files アプリケーション (django.contrib.staticfiles) がインストールされている場合のみ使用できます。

staticfiles ドキュメントの description を参照してください。

デフォルトのオプション

コマンドによっては独自のカスタムオプションを使用できるものもありますが、どのコマンドでもデフォルトでは以下のオプションが使用できます：

--pythonpath PYTHONPATH

与えられたファイルシステムのパスを Python sys.path モジュール属性に追加します。これが指定されていない場合、django-admin は PYTHONPATH 環境変数を使用します。

このオプションは manage.py では不要です。Python のパスの設定は manage.py が行ってくれるからです。

使用例:

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

--settings SETTINGS

使用する設定モジュールを指定します。設定モジュールは Python パッケージの構文である必要があります (例: mysite.settings)。これが指定されていない場合、 django-admin は DJANGO_SETTINGS_MODULE 環境変数を使用します。

このオプションは manage.py では不要です。デフォルトでは現在のプロジェクトの settings.py を使用するからです。

使用例:

django-admin migrate --settings=mysite.settings

--traceback

CommandError が発生した場合、完全なスタックトレースを表示します。デフォルトでは、 django-admin は CommandError が発生するとエラーメッセージを表示し、それ以外の例外が発生すると完全なスタックトレースを表示します。

このオプションは runserver では無視されます。

使用例:

django-admin migrate --traceback

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

コマンドがコンソールに表示する通知とデバッグ情報の量を指定します。

• 0 は出力なしを意味します。

• 1 は通常の出力を意味します（デフォルト）。

• 2 は詳細な出力を意味します。

• 3 は 非常に 詳細な出力を意味します。

このオプションは runserver では無視されます。

使用例:

django-admin migrate --verbosity 2

--no-color

カラー表示されたコマンドの出力を無効にします。一部のコマンドは、出力をカラー表示するようにフォーマットされます。たとえば、エラーは赤色でコンソールに表示され、SQL文はシンタックスハイライトされます。

使用例:

django-admin runserver --no-color

--force-color

シンタックスカラーリング で説明されているように、コマンドの出力が無効になる場合でも出力のカラー表示を強制します。例えば、色付きの出力を別のコマンドにパイプしたい場合などに使用します。

--skip-checks

コマンドを実行する前のシステムチェックをスキップします。このオプションは requires_system_checks コマンド属性が空のリストやタプルでない場合にだけ有効です。

使用例:

django-admin migrate --skip-checks

追加の便利機能

シンタックスカラーリング

DJANGO_COLORS

django-admin / manage.py コマンドは、ターミナルが ANSI カラー出力をサポートしている場合、色分けされた出力を使用します。 --force-color オプションが使用されていない限り、コマンドの出力を他のプログラムにパイプしてもカラー出力は使用されません。

Windows でのサポート

Windows 10 では、 Windows Terminal アプリケーション、 VS Code 、および PowerShell (仮想ターミナル処理が有効になっている場合) では色付きの出力が可能で、デフォルトでサポートされています。

Windows では、レガシーの cmd.exe ネイティブコンソールは ANSI エスケープシーケンスをサポートしていないため、デフォルトではカラー出力ができません。この場合、2つのサードパーティライブラリのどちらかが必要になります：

• colorama は、ANSI カラーコードを Windows API 呼び出しに変換する Python パッケージです。Django のコマンドはこのパッケージの存在を検出し、Unix ベースのプラット フォームと同じように、このパッケージのサービスを利用して出力に色をつけます。 colorama は pip でインストールできます：

  ...\> py -m pip install "colorama >= 0.4.6"
  

• ANSICON をインストールします。これは、 cmd.exe が ANSI カラーコードを処理できるようにするサードパーティツールです。Django のコマンドはこのツールの存在を検出し、Unix ベースのプラットフォームと同じように、このツールのサービスを利用して出力に色をつけます。

ターミナルカラーをサポートしているが、Django がサポートしていることを自動的に検出しない Windows の他のモダンなターミナル環境では、 ANSICON="on" という適切な環境変数を設定することで、 ANSICON のインストールを「偽装」することができます。

カラーをカスタマイズする

シンタックスハイライトに使う色はカスタマイズできます。Django には 3 つのカラーパレットが同梱されています：

• dark, 黒い背景に白いテキストを表示する端末に適しています。これはデフォルトのパレットです。

• light, これは白い背景に黒いテキストを表示する端末に適しています。

• nocolor, これはシンタックスハイライトを無効にします。

パレットを選択するには DJANGO_COLORS 環境変数を設定して使用したいパレットを指定します。例えば、UnixやOS/XのBASHシェルで light パレットを指定するには、ターミナルで以下のように実行します：

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 - 304以外の3XX HTTPリダイレクトサーバーレスポンス。

• http_not_found - 404 HTTP Not Found サーバーレスポンス。

• http_bad_request - 404 以外の 4XX HTTP Bad Request サーバーレスポンス。

• http_server_error - 5XX HTTP サーバーエラー。

• migrate_heading - マイグレーション管理コマンドの見出し。

• migrate_label - マイグレーション名。

これらの各ロールには、以下のリストから特定の前景色と背景色を割り当てることができます：

• black

• red

• green

• yellow

• blue

• magenta

• cyan

• white

これらの色はそれぞれ、以下の表示オプションを使って変更できます：

• bold

• underscore

• blink

• reverse

• conceal

色の指定は、次のいずれかのパターンに従います：

• role=fg

• role=fg/bg

• role=fg,option,option

• role=fg/bg,option,option

ここで role は有効な色の役割の名前、 fg は描画色、 bg は背景色、そしてそれぞれの option は色を変更するオプションの一つです。複数の色の指定はセミコロンで区切ります。たとえば以下のようにします：

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

これを指定すると、エラーは青地に黄色の点滅で表示され、通知はマゼンタで表示されます。それ以外の色の役割には色を付けません。

色はベースパレットを拡張して指定することもできます。色指定にパレット名を入れると、そのパレットが意味するすべての色が読み込まれます。つまり：

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

これを指定すると、light カラーパレットのすべての色の使用が指定されますが、error と notice の色は指定どおりにオーバーライドされます。

Bash による補完

Bash シェルを使用している場合は、Django bash 補完スクリプトのインストールを検討してください。スクリプトは Django のソース配布元の extras/django_bash_completion にあります。このスクリプトを使うと、django-admin と manage.py コマンドで tab キーによる補完が有効になります。使い方を説明すると、

• まず、django-admin とタイプします。

• [TAB] キーをクリックし、利用できるオプション一覧を表示します。

• sql とタイプし、[TAB] キーを押すと、名前が sql で始まるオプション一覧が表示されます。

独自のカスタムアクションを追加したい場合は、カスタム django-admin コマンドの作り方 を読んでください。

Black フォーマッタ

startproject, startapp, optimizemigration, makemigrations, squashmigrations によって作成された Python ファイルは、 black コマンドが PATH にあれば、それを使ってフォーマットされます。

もし black がグローバルにインストールされているが、現在のプロジェクトで使用したくない場合は、 PATH を明示的に設定できます：

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

stdout を使用するコマンドでは、必要に応じて出力を black にパイプできます：

django-admin inspectdb | black -

コードから管理コマンドを実行する

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

コードから管理コマンドを呼び出すには call_command() を使います。

name

呼び出すコマンドの名前またはコマンド・オブジェクト。オブジェクトがテストに必要でない限り、名前を渡すことが望ましいです。

*args

コマンドが受け付ける引数のリスト。引数は引数パーサに渡されるので、コマンドラインと同じスタイルで使用できます。たとえば、call_command('flush', '--verbosity=0') のようにします。

**options

コマンドラインで受け付ける名前付きオプション。オプションは引数パーサを起動することなくコマンドに渡されるため、正しい型を渡す必要があります。例えば、call_command('flush', verbosity=0) (ゼロは文字列ではなく整数でなければなりません)。

例:

from django.core import management
from django.core.management.commands import loaddata

management.call_command("flush", verbosity=0, interactive=False)
management.call_command("loaddata", "test_data", verbosity=0)
management.call_command(loaddata.Command(), "test_data", verbosity=0)

上の interactive オプションのように、引数を取らないコマンドオプションはキーワードとして True または False で渡されることに注意してください。

名前付き引数は、以下の構文のいずれかを使って渡すことができます：

# 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)

コマンドオプションの中には、 djangoo-admin や manage.py の代わりに call_command() を使用すると異なる名前になるものがあります。たとえば、 django-admin createsuperuser --no-input は call_command('createsuperuser', interactive=False) となります。 call_command() で使用するキーワード引数名を調べるには、コマンドのソースコードで parser.add_argument() に渡される dest 引数を確認してください。

複数のオプションを取るコマンドオプションは、リストで渡します：

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)