django-admin と manage.pyLink to this heading#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]\n$ manage.py <command> [options]\n$ python -m django <command> [options]\nWindows
...\\> django-admin <command> [options]\n...\\> manage.py <command> [options]\n...\\> py -m django <command> [options]\ncommand にはこのドキュメントに一覧されたコマンドの1つでなければなりません。options はオプションで、与えられたコマンドで利用できる 0 個以上のオプションを指定します。
django-admin help を実行すると、使用方法の情報と、各アプリケーションが提供するコマンドのリストが表示されます。
django-admin help --commands を実行すると、利用可能な全てのコマンドの一覧が表示されます。
django-admin help <command> を実行すると、与えられたコマンドの説明と利用可能なオプションの一覧が表示されます。
多くのコマンドは「アプリ名」のリストを取ります。1つの「アプリ名」はモデルを含むパッケージのベースネーム (basename) となります。たとえば、INSTALLED_APPS が文字列 'mysite.blog' を含む場合、アプリ名は blog になります。
django-admin version を実行すると、現在の Django のバージョンが表示されます。
出力は、次のように PEP 440 で説明されたスキーマに従います。
\n1.4.dev17026\n1.4a1\n1.4\nサポートされている場合に --verbosity を使うと、django-admin がコンソールに表示する通知とデバッグ情報の量を指定できます。
checkLink to this heading#システムチェック フレームワーク を使用して、Django プロジェクト全体のよくある問題を検査します。
\nデフォルトでは、全てのアプリがチェックされます。アプリのサブセットをチェックするには、次のようにアプリのラベルの一覧を引数として渡します。
\ndjango-admin check auth admin myapp\nシステムチェック フレームワークは、 タグでカテゴリ化された さまざまな種類のチェックを実行します。これらのタグを使用すると、特定のカテゴリ内のタグだけに実行するチェックを制限できます。たとえば、モデルと互換性のチェックだけを実行するには、次のコマンドを実行します。
\ndjango-admin check --tag models --tag compatibility\nデータベースアクセスが必要なチェックを実行するには、次のようにデータベースを指定します。
\ndjango-admin check --database default --database other\nデフォルトでは、これらのチェックは実行されません。
\n利用可能なタグを一覧します。
\nデプロイメントの設定にだけ関係のある、いくつかの追加チェックを有効化します。
\nこのオプションはローカルの開発環境で使えますが、ローカルの開発の設定モジュールは本番の設定の多くがないかもしれないため、おそらく DJANGO_SETTINGS_MODULE 環境変数を設定するか、--settings オプションを渡すことで、異なる設定モジュールを指定したくなるでしょう。
django-admin check --deploy --settings=production_settings\nあるいは、(--settings を省略して) 正しい設定が使用されていることを検証するために、本番かステージングのデプロイメントで直接実行することも可能です。
0 以外のステータスでコマンドを終了させるメッセージレベルを指定します。デフォルトは ERROR です。
compilemessagesLink to this heading#ビルトインの gettext サポートで使用できるように、makemessages が作成した .po ファイルを .mo ファイルにコンパイルします。詳しくは 国際化とローカライズ を参照してください。
処理する locale を指定します。提供されなかった場合、すべてのロケールが処理されます。
\n処理から除外する locale を指定します。提供されなかった場合、どのロケールも除外されません。
\nfuzzy な翻訳 をコンパイルされたファイルに含めます
\n使用例:
\ndjango-admin compilemessages --locale=pt_BR\ndjango-admin compilemessages --locale=pt_BR --locale=fr -f\ndjango-admin compilemessages -l pt_BR\ndjango-admin compilemessages -l pt_BR -l fr --use-fuzzy\ndjango-admin compilemessages --exclude=pt_BR\ndjango-admin compilemessages --exclude=pt_BR --exclude=fr\ndjango-admin compilemessages -x pt_BR\ndjango-admin compilemessages -x pt_BR -x fr\n与えられた glob スタイルのパターンに一致するディレクトリを無視します。 何度も無視するためには複数回使用してください。
使用例:
\ndjango-admin compilemessages --ignore=cache --ignore=outdated/*/locale\ncreatecachetableLink to this heading#設定ファイルからの情報を使用して、データベース キャッシュ バックエンドで使用するためのキャッシュテーブルを作成します。詳細な情報については、 Django のキャッシュフレームワーク を参照してください。
\nキャッシュテーブルを作成するデータベースを指定します。デフォルトは default です。
実行予定の SQL を、実際には実行せずに出力します。これにより、SQL をカスタマイズしたり、マイグレーション フレームワークを使用できます。
\ndbshellLink to this heading#USER や PASSWORD などの設定で指定されたコネクション パラメータを使用して、ENGINE 設定で指定されたデータベースエンジン用のコマンドライン クライアントを実行します。
PostgreSQL の場合、psql コマンドライン クライアントが実行されます。
MySQL の場合、mysql コマンドライン クライアントが実行されます。
SQLite の場合、sqlite3 コマンドライン クライアントが実行されます。
Oracle の場合、sqlplus コマンドライン クライアントが実行されます。
このコマンドは、プログラム名 (psql、mysql、sqlite3、sqlplus) の呼び出しで正しい場所にあるプログラムが見つかるように PATH が設定されているを想定しています。プログラムの場所を手動で指定する方法はありません。
シェルをオープンするデータベースを指定します。デフォルトは default です。
-- 区切り文字に続く引数は、ベースのコマンドライン クライアントに渡されます。たとえば、PostgreSQL では、次のように psql コマンドの -c フラグを使うことで、素の SQL クエリを直接実行できます。
Linux / macOS
$ django-admin dbshell -- -c 'select current_user'\n current_user\n--------------\n postgres\n(1 row)\nWindows
...\\> django-admin dbshell -- -c 'select current_user'\n current_user\n--------------\n postgres\n(1 row)\nMySQL/MariaDB では、次のように mysql の -e フラグを使用すると実行できます。
Linux / macOS
$ django-admin dbshell -- -e "select user()"\n+----------------------+\n| user() |\n+----------------------+\n| djangonaut@localhost |\n+----------------------+\nWindows
...\\> django-admin dbshell -- -e "select user()"\n+----------------------+\n| user() |\n+----------------------+\n| djangonaut@localhost |\n+----------------------+\ndiffsettingsLink to this heading#現在の設定ファイルと Django のデフォルトの設定 (または他の --default で指定された設定ファイル) の違いを表示します。
デフォルトに現れない設定には "###" が続きます。たとえば、デフォルト設定が ROOT_URLCONF を定義していない場合、diffsettings の出力内の ROOT_URLCONF の後には "###" が表示されます
Django のデフォルト値が設定されていたとしても、すべての設定を表示する。このような設定には、前に "###" という接頭辞が付きます。
現在の設定の比較対象にする設定モジュール。空にすると、Django のデフォルトの設定と比較します。
\n出力フォーマットを指定します。指定可能な値は hash と unified です。hash はデフォルトのモードで、上に説明したような出力を表示します。unified は diff -u に似た出力を表示します。デフォルトの設定はマイナス記号が前に付き、その後にプラス記号が前についた変更された設定が続きます。
dumpdataLink to this heading#名前を指定したアプリケーションと関連するデータベースの中のすべてのデータを、標準出力にアウトプットします。
\nアプリケーション名が指定されなかった場合、インストールされたすべてのアプリケーションをダンプします。
\ndumpdata のアウトプットは loaddata に対するインプットして使用できます。
dumpdata の出力をファイルとして保存すると、 テスト の フィクスチャ や、 初期データ として活用できます。
dumpdata は、ダンプするレコードを選択するために、モデルのデフォルトのマネージャを使用することに注意してください。カスタム マネージャ をデフォルトのマネージャとして使用していて、利用できるレコードの一部をフィルタリングしている場合、必ずしもすべてのオブジェクトがダンプされるわけではありません。
レコードをダンプする際に、フィルタリングまたは変更される可能性があるカスタム マネージャーの代わりに、Django のベース マネージャを使用します。
\n出力のシリアライズフォーマットを指定します。デフォルトは JSON です。対応フォーマットは シリアライズフォーマット に一覧があります。
\n出力で使用するインデントのスペースの数を指定します。デフォルトは None で、全てのデータを1行で表示します。
(app_label.ModelName の形式で指定された) 特定のアプリケーションやモデルがダンプされるのを防ぎます。モデル名を指定した場合には、アプリケーション全体ではなく、そのモデルだけが除外されます。アプリケーション名とモデル名を混ぜることもできます。
複数のアプリケーションを除外したいときは、--exclude を複数回渡してください。
django-admin dumpdata --exclude=auth --exclude=contenttypes\nデータをダンプするデータベースを指定します。デフォルトは default です。
natural_key() モデルメソッドを使用して、任意の外部キーと多対多リレーションを、メソッドを定義している種類のオブジェクトにシリアルライズします。contrib.auth の Permission オブジェクトや contrib.contenttypes の ContentType オブジェクトをダンプする場合、おそらくこのフラグを使う必要があります。このオプションと次のオプションの詳細については、ナチュラルキー のドキュメントを参照しください。
このオブジェクトのシリアライズされたデータの主キーを省略します。これが省略できるのは、デシリアライズ時に計算できるためです。
\nカンマで区切られた主キーのリストで指定されたオブジェクトだけを出力します。これは1つのモデルをダンプするときのみ有効です。デフォルトでは、モデルのすべてのレコードが出力されます。
\nシリアライズされたデータを書き込むファイルを指定します。デフォルトでは、データは標準出力に出力されます。
\nこのオプションが設定されていて、 --verbosity が 0 (デフォルト) より大きい場合、ターミナルにプログレスバーが表示されます。
出力ファイルは、ファイル名の最後に対応する拡張子をつけることで、 bz2、gz、lzma、xz のいずれかの形式で圧縮できます。たとえば、データを圧縮された JSON ファイルとして出力するには、次のようにします：
django-admin dumpdata -o mydata.json.gz\nflushLink to this heading#データベースからすべてのデータを削除し、同期後のハンドラを再実行します。マイグレーションが適用されたテーブルはクリアされません。
\n空のデータベースから始めて、すべてのマイグレーションを再実行したい場合は、代わりにデータベースを削除して再作成してから migrate を実行してください。
すべてのユーザープロンプトを表示しません。
\nフラッシュするデータベースを指定します。デフォルトは default です。
inspectdbLink to this heading#NAME 設定で指定されたデータベースのテーブルをイントロスペクトし、 Django モデルモジュール (models.py ファイル) を標準出力に出力します。
引数にテーブルやビューの名前を渡すことで、検査するテーブルやビューを選択できます。引数を指定しなかった場合、 --include-views オプションが使用された場合のみ、ビューのモデルが作成されます。PostgreSQL で --include-partitions オプションが使用された場合、パーティションテーブルのモデルが作成されます。
Django で使いたいレガシーデータベースがある場合に使ってください。このスクリプトはデータベースを検査し、各テーブルのモデルを作成します。
\nご想像の通り、作成されたモデルはテーブルのすべてのフィールドに対して属性を持ちます。 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 コメントを挿入します。
この機能は、決定的なモデル生成としてではなく、ショートカットとして意図されています。 この機能を実行した後、生成されたモデルを自分で見て、カスタマイズしてください。特に、他のモデルを参照するモデルが適切に並ぶように、モデルの順序を並べ替える必要があるでしょう。
\nDjango はモデルフィールドに default が指定されても、データベースのデフォルト値を作成しません。 同様に、データベースのデフォルト値はモデルフィールドのデフォルト値に変換されませんし、 inspectdb によって検出されることもありません。
デフォルトでは、 inspectdb は非管理モデルを作成します。 つまり、モデルの Meta クラスで managed = False を指定することで、 Django は各テーブルの作成、変更、削除を管理しないようになります。テーブルのライフサイクルを Django に管理させたい場合は、 managed オプションを True に変更する必要があります (あるいは、 True がデフォルト値なので削除してください)。
--include-views が使用されている場合、モデルはマテリアライズドビューのために作成されます。
モデルは外部テーブル用に作成されます。
--include-views が使用されている場合、モデルはマテリアライズドビューのために作成されます。
--include-partitions が使用されている場合、モデルはパーティションテーブルに対して作成されます。
イントロスペクトするデータベースを指定します。デフォルトは default です。
このオプションを指定すると、パーティション用のモデルも作成されます。
\nPostgreSQL 向けのサポートのみが実装されています。
\nこのオプションを指定すると、データベースビュー用のモデルも作成されます。
\nloaddataLink to this heading#指定された フィクスチャ の内容を検索してデータベースにロードします。
\nデータを読み込むデータベースを指定します。デフォルトは default です。
フィクスチャが最初に生成されてから削除された可能性のあるフィールドやモデルを無視します。
\nすべてのアプリでフィクスチャを探すのではなく、一つのアプリでフィクスチャを探すように指定します。
\nstdin から読み込む フィクスチャの シリアライズフォーマット (json や xml など) を指定します。
(app_label または app_label.ModelName の形で) 指定されたアプリケーションやモデルからのフィクスチャの読み込みを除外します。複数のアプリやモデルを除外するには、このオプションを複数回使います。
stdin からフィクスチャを読み込むLink to this heading#sys.stdin から入力を読み込むには、フィクスチャ名としてハイフンを使用します。たとえば下記のようにします：
django-admin loaddata --format=json -\nstdin から読み込む場合、 --format オプションで入力の シリアライズフォーマット (例 json や xml) を指定する必要があります。
stdin からの読み込みは、標準入出力をリダイレクトするのに便利です。たとえば：
django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -\ndumpdata コマンドは loaddata の入力を生成するために使用できます。
makemessagesLink to this heading#現在のディレクトリのソースツリー全体を走査し、翻訳が必要な文字列をすべて取り出します。conf/locale ディレクトリ (Django ツリーの場合) か locale ディレクトリ (プロジェクトとアプリケーションの場合) にメッセージファイルを作成 (または更新) します。メッセージファイルを変更した後は、組み込みの gettext サポートを使うために compilemessages でコンパイルする必要があります。詳しくは 国際化のドキュメント を参照してください。
このコマンドは設定を必要としません。しかし、設定が構成されていない場合、コマンドは MEDIA_ROOT と STATIC_ROOT ディレクトリを無視したり、 LOCALE_PATHS をインクルードしたりすることはできません。
利用可能な全ての言語に対してメッセージファイルを更新します。
\n検査するファイル拡張子のリストを指定します (デフォルト: html、txt、py、 js (--domain が djangojs の場合)。
使用例:
\ndjango-admin makemessages --locale=de --extension xhtml\n複数の拡張子はカンマで区切るか、-e または --extension を複数回使用してください：
django-admin makemessages --locale=de --extension=html,txt --extension xml\n処理する場所 (locale) を指定します。
\n処理から除外する locale を指定します。提供されなかった場合、どのロケールも除外されません。
\n使用例:
\ndjango-admin makemessages --locale=pt_BR\ndjango-admin makemessages --locale=pt_BR --locale=fr\ndjango-admin makemessages -l pt_BR\ndjango-admin makemessages -l pt_BR -l fr\ndjango-admin makemessages --exclude=pt_BR\ndjango-admin makemessages --exclude=pt_BR --exclude=fr\ndjango-admin makemessages -x pt_BR\ndjango-admin makemessages -x pt_BR -x fr\nメッセージファイルのドメインを指定します。サポートされているオプションは以下の通りです:
\n*.py、*.html、*.txt ファイルすべてに対して django (デフォルト)
*.js ファイルに対して djangojs
新しい翻訳文字列を探すときに、ディレクトリへのシンボリックリンクをたどります。
\n使用例:
\ndjango-admin makemessages --locale=de --symlinks\n与えられた glob スタイルのパターンに一致するファイルやディレクトリを無視します。 何度も無視するためには複数回使用してください。
次のパターンはデフォルトで使われます: 'CVS'、'.*'、'*~'、'*.pyc'。
使用例:
\ndjango-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html\n--ignore のデフォルト値を無効化します。
言語ファイル内で、長いメッセージ行の複数行への分割を無効化します。
\n言語ファイル内に '#: filename:line' コメント行を書き込むのを抑制します。このオプションを使うと、技術的な翻訳者がそれぞれのメッセージの文脈を理解することが難しくなります。
言語ファイル中のコメント行 #: filename:line をコントロールします。オプションは下記です：
full (省略時のデフォルト): ファイル名と行番号の両方を含む行を表示します。
file: 行番号は省略されます。
never: 行の出力が抑制されます (--no-location と同じ)。
gettext 0.19 以降が必要です。
廃止されたメッセージ文字列を .po ファイルから削除します。
.po ファイルが作成される前に生成される一時的な .pot ファイルを削除しないようにします。最終的な言語ファイルが生成されるのを妨げるようなエラーをデバッグするために有用です。
makemigrationsLink to this heading#検出されたモデルの変更に基づいて、新しいマイグレーションを作成します。マイグレーションおよびそのアプリとの関係は、詳しくは マイグレーションのドキュメント で説明しています。
\n1つ以上のアプリ名を引数として与えると、作成するマイグレーションを、指定されたアプリとそれに必要な依存関係 (たとえば、外部キーで繋がれた他のテーブルなど) に限定されます。
\nマイグレーションを migrations ディレクトリが存在しないアプリに追加するには、makemigrations にアプリの app_label を付けて実行します。
すべてのユーザープロンプトを抑制します。もし、抑制されたプロンプトが自動的に解決できなかった場合は、エラーコード 3 で終了します。
\n手動で編集するために、指定されたアプリに対する空のマイグレーションを出力します。このオプションは詳しいユーザーのためのもので、マイグレーションのフォーマット、マイグレーション・オペレーション、およびマイグレーション間の依存関係について十分理解していない限り、使うべきではありません。
\n実際にマイグレーションをディスクには書き込まず、作成される予定のマイグレーションを表示します。このオプションを --verbosity 3 オプションと併用することで、書き込まれる予定のマイグレーションファイルの内容そのものを表示できます。
マイグレーションで発生するコンフリクトの修復を有効にする
\n生成されたマイグレーションに名前を付けることができます。名前は有効な Python 識別子 でなければなりません。
\nDjango のバージョンとタイムスタンプヘッダなしでマイグレーションファイルを生成します。
\nマイグレーションを伴わないモデル変更が検出された場合に、 makemigrations を 0 以外のステータスで終了するようにします。これは --dry-run を意味します。
ログ出力と入力プロンプトを stderr に流し、生成されたマイグレーションファイルのパスのみを stdout に書き込みます。
モデルの変更を最新のマイグレーションにマージし、その結果生じるオペレーションを最適化します。
\n更新されたマイグレーションは生成された名前を持ちます。以前の名前を保持するには、--name を使って設定してください。
migrateLink to this heading#データベースの状態を、現在のモデルとマイグレーションのセットを基づいて同期します。マイグレーションおよびそのアプリとの関係については、詳しくは マイグレーションのドキュメント で説明しています。
\nこのコマンドの動作は、次のように与えられた引数によって変化します。
\n引数なし: 全てのアプリが、それぞれが持つマイグレーションを全て実行します。
<app_label>: 指定したアプリに最新のマイグレーションまで実行させます。依存関係によっては、他のアプリのマイグレーションも実行される場合もあります
<app_label> <migrationname>: データベーススキーマを、指定した名前のマイグレーションが実行された状態になるようにします。指定したよりも後のマイグレーションは適用されません。指定されたより前のマイグレーションがすでに適用されていた場合など、指定の仕方によってはマイグレーションが実行できない場合があります。アプリに対するすべてのマイグレーションの適用をリセットするには、zero という名前を指定してください。指定したアプリ名で一意であれば、マイグレーション名のプレフィックス、例えば 0001 を使用できます。アプリに適用されたマイグレーションをすべて元に戻すには zero という名前を指定してください。
マイグレートするデータベースを指定します。デフォルトは default です。
（上記のルールに従って）ターゲットのマイグレーションまでを適用されたものとしてマークしますが、データベーススキーマを変更するSQLを実際には実行しません。
\nこれは上級ユーザが手動で変更を適用する場合に、現在のマイグレーション状態を直接操作することを想定しています。 --fake を使用すると、マイグレーションを正しく実行するためにマイグレーション状態テーブルを手動で回復する必要がある状態になる危険性があることに注意してください。
マイグレーションに含まれる全ての CreateModel オペレーションで作成された全てのモデルの名前を持つデータベーステーブルが既に存在する場合、 Django がアプリの初期マイグレーションをスキップできるようにします。このオプションは、マイグレーションを使用する前のデータベースに対してマイグレーションを初めて実行するときに使用することを想定しています。しかし、このオプションは、テーブル名の一致以外のデータベーススキーマの一致をチェックしないので、既存のスキーマが初期マイグレーションに記録されているものと一致することを確信している場合のみ安全に使用できます。
指定された migrate コマンドに対して実行されるマイグレーション・オペレーションを表示します。
マイグレーションせずにアプリ用のテーブルを作成できるようにします。これは推奨されませんが、マイグレーションフレームワークは何百ものモデルがある大規模なプロジェクトでは遅すぎることがあります。
\nすべてのユーザープロンプトを表示しません。プロンプトの例は、古くなったコンテンツタイプの削除に関する質問です。
\n適用されていないマイグレーションが検出された場合に、 migrate を 0 以外のステータスで終了するようにします。
存在しないマイグレーションを django_migrations テーブルから削除します。これはスカッシュしたマイグレーションによって置き換えられたマイグレーションファイルが削除された場合に便利です。詳細は マイグレーションのスカッシュ (Squash) を参照してください。
optimizemigrationLink to this heading#指定されたマイグレーション・オペレーションを最適化し、既存のファイルを上書きします。マイグレーションに手動でコピーしなければならない関数が含まれている場合、このコマンドは _optimized で終わる新しいマイグレーションファイルを作成し、指定されたマイグレーションを置き換えます。
マイグレーションを最適化できる場合に、 optimizemigration を 0 以外のステータスで終了するようにします。
runserverLink to this heading#ローカルマシンで軽量の開発用ウェブサーバを起動します。デフォルトでは、IPアドレス 127.0.0.1 のポート 8000 で動作します。IPアドレスとポート番号を明示的に渡すこともできます。
このスクリプトを通常の権限を持つユーザ（推奨）で実行した場合、小さいポート番号のポートを起動するためのアクセス権がない可能性があります。小さいポート番号はスーパーユーザ（root）のために予約されています。
\nこのサーバーは WSGI_APPLICATION 設定で指定された WSGI アプリケーションオブジェクトを使用します。
このサーバーを本番環境で使用しないでください 。セキュリティ監査もパフォーマンステストも行っていません。(そして、それは将来も変わりません。私たちは Web フレームワークを作るのが仕事であって、 Web サーバを作るのが仕事ではないので、本番環境を扱えるようにこのサーバを改良するのは Django の範囲外です)。
\n開発サーバーは必要に応じてリクエストごとにPythonコードを自動的にリロードします。コード変更の効果を得るためにサーバーを再起動する必要はありません。しかしながら、ファイルの追加のようないくつかの行動は再起動をトリガーしません、このような場合はサーバーを再起動する必要があります。
\nLinux や MacOS を使用していて、 pywatchman と Watchman サービスの両方をインストールしている場合、カーネルシグナルがサーバーの自動再ロードに使用されます(毎秒ファイルの変更タイムスタンプをポーリングするのではなく)。これにより、大規模なプロジェクトでのパフォーマンスが改善され、コード変更後の 応答時間が短縮され、変更検出がより強固になり、消費電力が削減されます。Django は pywatchman 1.2.0 以降をサポートしています。
サーバを起動したとき、そしてサーバ起動中に 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 文字のみからなる文字列も使用できます。
\nstaticfiles contrib アプリが有効になっている場合 (新しいプロジェクトのデフォルト)、 runserver コマンドは独自の runserver コマンドで上書きされます。
サーバの各リクエストとレスポンスのログは django.server ロガーに送られます。
\n自動リローダを無効にします。これは、もし特定の Python モジュールが既にメモリに読み込まれている場合、サーバの実行中に行った Python コードの変更は 反映 されないことを意味します。
\n開発サーバーでのスレッドの使用を無効にします。デフォルトではサーバーはマルチスレッドです。
\n開発用サーバーで IPv6 を使用します。これにより、デフォルトの IP アドレスが 127.0.0.1 から ::1 に変わります。
IP アドレス 127.0.0.1 上でポート 8000 を使用する場合:
django-admin runserver\nIP アドレス 1.2.3.4 上でポート 8000 を使用する場合:
django-admin runserver 1.2.3.4:8000\nIP アドレス 127.0.0.1 上でポート 7000 を使用する場合:
django-admin runserver 7000\nIP アドレス 1.2.3.4 上でポート 7000 を使用する場合:
django-admin runserver 1.2.3.4:7000\nIPv6 アドレス ::1 上でポート 8000 を使用する場合:
django-admin runserver -6\nIPv6 アドレス ::1 上でポート 7000 を使用する場合:
django-admin runserver -6 7000\nIPv6 アドレス 2001:0db8:1234:5678::9 上でポート 7000 を使用する場合:
django-admin runserver [2001:0db8:1234:5678::9]:7000\nIPv4 アドレスのホスト localhost 上でポート 8000 を使用する場合:
django-admin runserver localhost:8000\nIPv6 アドレスのホスト localhost 上でポート 8000 を使用する場合:
django-admin runserver -6 localhost:8000\nデフォルトでは、開発サーバはサイトの静的ファイル (CSS ファイルや画像、 MEDIA_URL 以下にあるものなど) を配信しません。Django が静的メディアを配信するように設定したい場合は、 静的ファイル (画像、JavaScript、CSS など) を管理する を参照してください。
Django の runserver コマンドは WSGI サーバーを提供します。ASGI で実行するには、 ASGI サーバー を使う必要があります。Django Daphne プロジェクトは、 runserver との統合 を提供しています。
sendtestemailLink to this heading#（Django によるメール送信が動作していることを確認するために）指定した受信者にテストメールを送信します。たとえば以下のようにします：
\ndjango-admin sendtestemail foo@example.com bar@example.com\nいくつかのオプションがあるので、次のようにそれらを任意に組み合わせて使用できます。
\nmail_managers() を使用して MANAGERS で指定されたメールアドレスにメールします。
mail_admins() を使用して ADMINS で指定されたメールアドレスにメールします。
shellLink to this heading#Python のインタラクティブ・インタープリタを開始します。
\n使用するシェルを指定します。デフォルトでは、Django はインストールされている場合には IPython または bpython を使用します。両方インストールされている場合には、次のようにして使いたいシェルを指定してください。
\nIPython:
\ndjango-admin shell -i ipython\nbpython:
\ndjango-admin shell -i bpython\n"リッチな" シェルをインストールしているが、"プレーン" な Python インタプリタを強制的に使いたい場合は、インターフェイス名として python を次のように使用します：
django-admin shell -i python\n"プレーン" Python インタプリタのスタートアップスクリプトを読み込まないようにします。デフォルトでは PYTHONSTARTUP 環境変数か ~/.pythonrc.py スクリプトが指すスクリプトが読み込まれます。
以下のように、コマンドを文字列で渡して、Django として実行できます：
\ndjango-admin shell --command="import django; print(django.__version__)"\n標準入力にコードを渡して実行することもできます。たとえば：
\n$ django-admin shell <<EOF\n> import django\n> print(django.__version__)\n> EOF\nWindowsでは、そのプラットフォームでの select.select() の実装制限に応じて REPL が出力されます。
showmigrationsLink to this heading#プロジェクト内のすべてのマイグレーションを表示します。2つの形式から選択できます：
\nDjango が知っている全てのアプリ、各アプリで利用可能なマイグレーション、各マイグレーションが適用されているかどうか（マイグレーション名の横に [X] と表示されます）を一覧表示します。また、 --verbosity が 2 以上の場合、適用された日時も表示されます。
マイグレーションのないアプリもリストアップされますが、その下に (no migrations) と表示されます。
これはデフォルトの出力形式です。
\nDjango が適用するマイグレーションの計画を表示します。 list と同様に、適用されたマイグレーションは [X] でマークされます。また、 --verbosity が 2 以上の場合、マイグレーションの全ての依存関係も表示されます。
app_label 引数によって出力は制限されますが、提供されたアプリの依存関係も含めることができます。
検査するデータベースを指定します。デフォルトは default です。
sqlflushLink to this heading#flush コマンドで実行される SQL 文を表示します。
SQLを表示するデータベースを指定します。デフォルトは default です。
sqlmigrateLink to this heading#指定された名前のマイグレーション用の SQL を出力します。これは、制約名の解決に使用するアクティブなデータベース接続を必要とします。つまり、後で適用したいデータベースのコピーに対して SQL を生成する必要があります。
\nsqlmigrate は出力に色をつけないことに注意してください。
マイグレーションの適用を取り消すSQLを生成します。デフォルトでは、マイグレーションを順方向に実行するための SQL が生成されます。
\nSQL を生成するデータベースを指定します。デフォルトは default です。
sqlsequenceresetLink to this heading#指定されたアプリ名のシーケンスをリセットする SQL 文を出力します。
\nシーケンスは、自動的にインクリメントされるフィールドの次に利用可能な番号を追跡するために、いくつかのデータベースエンジンで使用されるインデックスです。
\nこのコマンドを使用して、シーケンスが自動的にインクリメントされたフィールドデータと同期していないケースを修正するSQLを生成できます。
\nSQLを表示するデータベースを指定します。デフォルトは default です。
squashmigrationsLink to this heading#migration_name までの app_label のマイグレーションを、可能であればより少ないマイグレーションにスカッシュします。スカッシュされたマイグレーションは、スカッシュされていないマイグレーションと安全に共存できます。詳しくは マイグレーションのスカッシュ (Squash) を参照してください。
start_migration_name を指定すると、 Django はこのマイグレーションから始まり、このマイグレーションを含むマイグレーションだけを取り込みます。これは RunPython と django.db.migrations.operations.RunSQL マイグレーション・オペレーションのスカッシュ制限を緩和するのに役立ちます。
スカッシュされたマイグレーションを生成する際に、オプティマイザを無効にします。デフォルトでは、 Django はマイグレーションする際の処理を最適化し、結果のファイルサイズを小さくしようとします。この処理が失敗したり、正しくないマイグレーションを作成したりする場合は、このオプションを使ってください。最適化は安全であることを意図しているので、その動作について Django バグレポートを提出してください。
\nすべてのユーザープロンプトを表示しません。
\nスカッシュされたマイグレーションの名前を設定します。省略した場合は、最初と最後のマイグレーションの間に _squashed_ を加えた名前になります。
Django のバージョンとタイムスタンプのヘッダなしで、スカッシュしたマイグレーションファイルを生成します。
\nstartappLink to this heading#指定されたアプリ名の Django アプリディレクトリ構造を、カレントディレクトリか、指定された保存先に作成します。
\nデフォルトでは、新しいディレクトリ には models.py ファイルと他のアプリテンプレートファイルが含まれます。アプリ名だけが与えられた場合、アプリディレクトリは現在の作業ディレクトリに作成されます。
オプションで保存先を指定すると、 Django は新しいディレクトリを作成するのではなく、既存のディレクトリを使用します。現在の作業ディレクトリを表すには "." を使用してください。
\n例:
\ndjango-admin startapp myapp /Users/jezdez/Code/myapp\nカスタムアプリテンプレートファイルを含むディレクトリへのパス、または圧縮されていないアーカイブ (.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\nDjangoは、アプリテンプレートファイルを含む圧縮アーカイブへのURL (http、https、ftp) も受け付けることができ、それらをダウンロードしてリアルタイムで展開します。
たとえば、GitHub の zip ファイルとしてリポジトリを公開する機能を使えば、次のような URL を使うことができます：
\ndjango-admin startapp --template=https://github.com/githubuser/django-app-template/archive/main.zip myapp\nアプリテンプレート内のどの拡張子をテンプレートエンジンでレンダリングするかを指定します。デフォルトは py です。
(--extension にマッチするものに加えて) アプリテンプレート内のどのファイルをテンプレートエンジンでレンダリングするかを指定します。デフォルトは空のリストです。
.git と __pycache__ に加えて、アプリテンプレート内のどのディレクトリを除外するかを指定します。このオプションを指定しない場合、__pycache__ という名前のディレクトリや、. で始まるディレクトリは除外されます。
マッチする全てのファイルに使用される テンプレートコンテキスト は以下の通りです：
startapp コマンドに渡されたオプション (コマンドでサポートされているオプションに限る)
app_name -- コマンドに渡されたアプリ名
app_directory -- 新規作成されたアプリのフルパス
camel_case_app_name -- キャメルケース形式のアプリ名
docs_version -- ドキュメントのバージョン: 'dev' または 1.x'
django_version -- Django のバージョン、例えば '2.0.3' 。
startprojectLink to this heading#指定されたプロジェクト名の Django プロジェクトディレクトリ構造を、カレントディレクトリか指定された保存先に作成します。
\nデフォルトでは、 新しいディレクトリ には manage.py とプロジェクトパッケージ (settings.py と他のファイルを含む) があります。
プロジェクト名だけを指定した場合、プロジェクトディレクトリとプロジェクトパッケージは <projectname> という名前になり、プロジェクトディレクトリは現在の作業ディレクトリに作成されます。
オプションで保存先を指定すると、 Django はその既存のディレクトリをプロジェクトディレクトリとして使用し、 manage.py とその中にプロジェクトパッケージを作成します。現在の作業ディレクトリを表すには "." を使用してください。
例:
\ndjango-admin startproject myproject /Users/jezdez/Code/myproject_repo\nカスタムプロジェクトテンプレートのディレクトリ、ファイルパス、または URL を指定します。例と使い方は startapp --template のドキュメントを参照してください。
プロジェクトテンプレート内のどの拡張子をテンプレートエンジンでレンダリングするかを指定します。デフォルトは py です。
(--extension にマッチするものに加えて) プロジェクトテンプレート内のどのファイルをテンプレートエンジンでレンダリングするかを指定します。デフォルトは空のリストです。
.git と __pycache__ に加えて、プロジェクトテンプレート内のどのディレクトリを除外するかを指定します。このオプションを指定しない場合、__pycache__ という名前のディレクトリや、. で始まるディレクトリは除外されます。
使用される テンプレートコンテキスト は以下の通りです：
startproject コマンドに渡されたオプション (コマンドでサポートされているオプションに限る)
project_name -- コマンドに渡されたプロジェクト名
project_directory -- 新規作成されたプロジェクトのフルパス
secret_key -- SECRET_KEY 設定用のランダムなキー。
docs_version -- ドキュメントのバージョン: 'dev' または 1.x'
django_version -- Django のバージョン、例えば '2.0.3' 。
startapp で説明した レンダリングに関する警告 と 信頼されたコードに関する警告 も参照してください。
testLink to this heading#インストールされている全てのアプリのテストを実行します。詳しくは Django におけるテスト を参照してください。
\nテストが失敗したら直ちにテストの実行を停止し、失敗を報告します。
\nテストの実行に使われるテストランナークラスを制御します。この値は TEST_RUNNER 設定によって提供される値を上書きします。
すべてのユーザープロンプトを表示しません。典型的なプロンプトは、既存のテストデータベースの削除に関する警告です。
\ntest コマンドは指定された --testrunner の代わりにオプションを受け取ります。これらはデフォルトのテストランナーである DiscoverRunner のオプションです。
テスト実行の間、テストデータベースを保持します。これには、作成と破棄の両方のアクションを省略できるという利点があり、 特に大規模なテストスイートにおけるテストの実行時間を大幅に短縮できます。テストデータベースが存在しない場合は、最初の実行時に作成され、それ以降の実行時に保存されます。MIGRATE テスト設定が False でない限り、テストスイートを実行する前に、未適用のマイグレーションもテストデータベースに適用されます。
テストを実行する前に、テストの順番をランダムにします。これは、適切に分離されていないテストの検出に役立ちます。このオプションで生成されるテストの順番は、 与えられた整数シードの決定論的な関数です。シードが渡されない場合は、ランダムにシードが選ばれてコンソールに出力されます。特定のテスト順序を繰り返すには、シードを渡します。このオプションで生成されるテスト順序は Django の テスト順序における保証 を保持します。また、テストはテストケースクラスごとにグループ化されます。
\nシャッフルされた順序は、分離の問題を絞り込む際に有用な特別な一貫性を持っています。つまり、シードを指定してテストのサブセットを実行する場合、新しい順序はより小さなセットに制限されつつ、元のシャッフル順序を維持します。同様に、シードを同じに保ちながらテストを追加すると、元のテストの順序は新しい順序でも同じままです。
\nテストケースを逆の実行順序で並べ替えます。これは適切に分離されていないテストの副作用をデバッグする際に役立つかもしれません。 テストクラス によるグループ化は、このオプションを使用しても保持されます。 --shuffle と組み合わせて使用することで、特定のシードの順番を逆にできます。
テストを実行する前に DEBUG 設定を True に設定します。これはテストの失敗のトラブルシューティングに役立ちます。
失敗したテストの SQL ロギング を有効にします。もし --verbosity が 2 なら、パスしたテストのクエリも出力されます。
別々の並列プロセスでテストを実行します。現代のプロセッサは複数のコアを備えているため、これによってテストの実行速度を大幅に向上させることができます。
\n値を指定せずに --parallel を使用した場合、または値 auto を指定した場合、 multiprocessing.cpu_count() に従って各コアに 1 つのテストプロセスを実行します。これをオーバーライドするには、必要なプロセス数、たとえば --parallel 4 を渡すか、 DJANGO_TEST_PROCESSES 環境変数を設定します。
Django はテストケース (unittest.TestCase サブクラス) をサブプロセスに分散します。設定されたプロセス数よりもテストケースクラスの数が少ない場合、 Django はそれに応じてプロセス数を減らします。
各プロセスごとに個別のデータベースを持つため、異なるテストケースクラスが同じリソースにアクセスしないように注意が必要です。たとえば、複数のテストケースクラスがファイルシステムにアクセスするような場合には、各テストケースクラスごとに個別に一時ディレクトリを作成するようにしてください。
\n\nこのオプションはトレースバックを正しく表示するために、サードパーティの tblib パッケージが必要です：
$ python -m pip install tblib\nこの機能はWindowsでは使用できません。Oracleデータベースのバックエンドでも動作しません。
\nテストのデバッグ中に pdb を使用したい場合は、並列実行を無効にする必要があります (--parallel=1) 。そうしないと bdb.BdbQuit のようなメッセージが表示されます。
指定したタグ でマークされたテストのみを実行します。test --exclude-tag と組み合わせて複数回指定できます。
ロードに失敗したテストは常にマッチしたとみなされます。
\n指定したタグ でマークされたテストを除外します。test --tag と組み合わせて複数回指定できます。
unittest の -k オプション と同じように、テスト名のパターンにマッチするテストメソッドとクラスを実行します。複数回指定できます。
テストのエラーや失敗のたびに pdb デバッガを起動します。インストールされている場合は、代わりに ipdb が使用されます。
unittest の --buffer オプション と同じように、テストに合格した出力 (stdout と stderr) を破棄します。
Django はテストの開始時に faulthandler.enable() を自動的に呼び出します。これにより、インタプリタがクラッシュした場合にトレースバックを表示します。この動作を無効にするには --no-faulthandler を渡してください。
データベースのセットアップや総実行時間などのタイミングを出力します。
\n最も遅い N 個のテストケースを表示します（N=0 の場合はすべて）。
\n\ntestserverLink to this heading#(runserver のように) 与えられたフィクスチャのデータを使って Django 開発サーバを起動します。
たとえばこのコマンドは、：
\ndjango-admin testserver mydata.json\n... 以下のステップを実行します：
\ntest データベース で説明されているように、テスト用データベースを作成します。
与えられたフィクスチャからフィクスチャデータをテストデータベースに投入します。(フィクスチャの詳細については、上記の loaddata のドキュメントを参照してください)。
Django 開発サーバを実行します (runserver のように)。本番用データベースの代わりに、新しく作成したテスト用データベースを指定します。
これはいろいろな面で便利です：
\nユニットテスト を書くとき、フィクスチャデータを使ってビューがどのように動作するか、 testserver を使ってウェブブラウザでビューと手動でやりとりできます。
Django アプリケーションを開発していて、対話したいデータベースの "まっさらな" コピーがあるとします。データベースを フィクスチャ にダンプし (上で説明した dumpdata コマンドを使います)、そのデータを使って testserver で Web アプリケーションを実行します。この方法では、どんなデータの変更もテスト用のデータベースに対してだけ行われるため、柔軟にデータを変更できます。
このサーバは Python のソースコードの変更を (runserver のように) 自動的に検出することは しない ことに注意してください。しかし、テンプレートの変更は検出します。
デフォルトの 127.0.0.1:8000 とは異なるポート、または IP アドレスとポートを指定します。この値は runserver コマンドの引数と全く同じフォーマットで、全く同じ機能を果たします。
例:
\nポート7000で fixture1 と fixture2 を使ってテストサーバを動かすには、以下のようにします：
django-admin testserver --addrport 7000 fixture1 fixture2\ndjango-admin testserver fixture1 fixture2 --addrport 7000\n（上の2つは等価です。オプションがフィクスチャの引数の前でも後でも問題ないことを示すために、この2つを紹介しています）
\n1.2.3.4:7000 で test フィクスチャを使って実行するには、下記のようにします：
django-admin testserver --addrport 1.2.3.4:7000 test\nすべてのユーザープロンプトを表示しません。典型的なプロンプトは、既存のテストデータベースの削除に関する警告です。
\nいくつかのコマンドは、それを 実装した django.contrib アプリケーションが 有効に なっていないと利用できません。この節では、それらをアプリケーションごとに分類して説明します。
django.contrib.authLink to this heading#changepasswordLink to this heading#このコマンドは Django の 認証システム (django.contrib.auth) がインストールされている場合のみ利用できます。
ユーザのパスワードを変更できます。指定されたユーザの新しいパスワードを2回入力するよう求められます。入力が同じであれば、これが直ちに新しいパスワードになります。ユーザを指定しなかった場合、コマンドはユーザ名が現在のユーザと一致するパスワードを変更しようとします。
\nユーザーをクエリするデータベースを指定します。デフォルトは default です。
使用例:
\ndjango-admin changepassword ringo\ncreatesuperuserLink to this heading#このコマンドは Django の 認証システム (django.contrib.auth) がインストールされている場合のみ利用できます。
superuser アカウント (すべての権限を持ったユーザー) を作成します。このコマンドは、最初に superuser アカウントを作成する場合や、サイトの superuser アカウントをプログラムから自動生成する必要がある場合に便利です。
\n対話的に実行すると、このコマンドは新しいスーパーユーザアカウントのパスワードを要求します。非対話的に実行する場合、 DJANGO_SUPERUSER_PASSWORD 環境変数を設定することでパスワードを設定できます。そうでない場合、パスワードは設定されず、スーパーユーザーアカウントはパスワードが手動で設定されるまでログインできません。
非インタラクティブモードでは、 USERNAME_FIELD と必須フィールド (REQUIRED_FIELDS にリストされています) はコマンドライン引数で上書きされない限り、環境変数 DJANGO_SUPERUSER_<uppercase_field_name> にフォールバックします。例えば、 email フィールドを指定するには、環境変数 DJANGO_SUPERUSER_EMAIL を使用します。
すべてのユーザープロンプトを表示しません。もし、抑制されたプロンプトが自動的に解決できなかった場合は、エラーコード 1 で終了します。
\n新しいアカウントのユーザー名とメールアドレスはコマンドラインの --username と --email 引数で指定できます。これらのどちらかが与えられない場合、 createsuperuser は対話的に実行する際にその入力を要求します。
スーパーユーザ・オブジェクトを保存するデータベースを指定します。
\nデータの入力とバリデーションをカスタマイズしたい場合は、管理コマンドをサブクラス化して get_input_data() をオーバーライドします。既存の実装やメソッドのパラメータの詳細についてはソースコードを参照してください。たとえば、REQUIRED_FIELDS に ForeignKey があり、既存のインスタンスの主キーを入力する代わりにインスタンスを作成できるようにしたい場合に便利です。
django.contrib.contenttypesLink to this heading#remove_stale_contenttypesLink to this heading#このコマンドは Django の contenttypes アプリ (django.contrib.contenttypes) がインストールされている場合のみ利用できます。
（削除されたモデルの）古くなったコンテンツタイプをデータベースから削除します。削除されたコンテンツタイプに依存しているオブジェクトも削除されます。削除されたオブジェクトのリストが表示された後、削除を続行できます。
\n使用するデータベースを指定します。デフォルトは default です。
INSTALLED_APPS から削除された、以前にインストールされたアプリのものを含む、古くなったコンテンツタイプを削除します。デフォルトは False です。
django.contrib.gisLink to this heading#ogrinspectLink to this heading#このコマンドは、GeoDjango (django.contrib.gis) がインストールされている場合のみ使用できます。
GeoDjango のドキュメントの description を参照してください。
django.contrib.sessionsLink to this heading#clearsessionsLink to this heading#cron job に設定したり、直接実行することで、期限切れのセッションを削除できます。
\ndjango.contrib.staticfilesLink to this heading#collectstaticLink to this heading#このコマンドは static files アプリケーション (django.contrib.staticfiles) がインストールされている場合のみ使用できます。
staticfiles ドキュメントの description を参照してください。
findstaticLink to this heading#このコマンドは static files アプリケーション (django.contrib.staticfiles) がインストールされている場合のみ使用できます。
staticfiles ドキュメントの description を参照してください。
コマンドによっては独自のカスタムオプションを使用できるものもありますが、どのコマンドでもデフォルトでは以下のオプションが使用できます：
\n与えられたファイルシステムのパスを Python sys.path モジュール属性に追加します。これが指定されていない場合、django-admin は PYTHONPATH 環境変数を使用します。
このオプションは manage.py では不要です。Python のパスの設定は manage.py が行ってくれるからです。
使用例:
\ndjango-admin migrate --pythonpath='/home/djangoprojects/myproject'\n使用する設定モジュールを指定します。設定モジュールは Python パッケージの構文である必要があります (例: mysite.settings)。これが指定されていない場合、 django-admin は DJANGO_SETTINGS_MODULE 環境変数を使用します。
このオプションは manage.py では不要です。デフォルトでは現在のプロジェクトの settings.py を使用するからです。
使用例:
\ndjango-admin migrate --settings=mysite.settings\nCommandError が発生した場合、完全なスタックトレースを表示します。デフォルトでは、 django-admin は CommandError が発生するとエラーメッセージを表示し、それ以外の例外が発生すると完全なスタックトレースを表示します。
このオプションは runserver では無視されます。
使用例:
\ndjango-admin migrate --traceback\nコマンドがコンソールに表示する通知とデバッグ情報の量を指定します。
\n0 は出力なしを意味します。
1 は通常の出力を意味します（デフォルト）。
2 は詳細な出力を意味します。
3 は 非常に 詳細な出力を意味します。
このオプションは runserver では無視されます。
使用例:
\ndjango-admin migrate --verbosity 2\nカラー表示されたコマンドの出力を無効にします。一部のコマンドは、出力をカラー表示するようにフォーマットされます。たとえば、エラーは赤色でコンソールに表示され、SQL文はシンタックスハイライトされます。
\n使用例:
\ndjango-admin runserver --no-color\nシンタックスカラーリング で説明されているように、コマンドの出力が無効になる場合でも出力のカラー表示を強制します。例えば、色付きの出力を別のコマンドにパイプしたい場合などに使用します。
\nコマンドを実行する前のシステムチェックをスキップします。このオプションは requires_system_checks コマンド属性が空のリストやタプルでない場合にだけ有効です。
使用例:
\ndjango-admin migrate --skip-checks\ndango-admin / manage.py コマンドは、ターミナルが ANSI カラー出力をサポートしている場合、色分けされた出力を使用します。 --force-color オプションが使用されていない限り、コマンドの出力を他のプログラムにパイプしてもカラー出力は使用されません。
Windows 10 では、 Windows Terminal アプリケーション、 VS Code 、および PowerShell (仮想ターミナル処理が有効になっている場合) では色付きの出力が可能で、デフォルトでサポートされています。
\nWindows では、レガシーの cmd.exe ネイティブコンソールは ANSI エスケープシーケンスをサポートしていないため、デフォルトではカラー出力ができません。この場合、2つのサードパーティライブラリのどちらかが必要になります：
colorama は、ANSI カラーコードを Windows API 呼び出しに変換する Python パッケージです。Django のコマンドはこのパッケージの存在を検出し、Unix ベースのプラット フォームと同じように、このパッケージのサービスを利用して出力に色をつけます。 colorama は pip でインストールできます：
...\\> py -m pip install "colorama >= 0.4.6"\nANSICON をインストールします。これは、 cmd.exe が ANSI カラーコードを処理できるようにするサードパーティツールです。Django のコマンドはこのツールの存在を検出し、Unix ベースのプラットフォームと同じように、このツールのサービスを利用して出力に色をつけます。
ターミナルカラーをサポートしているが、Django がサポートしていることを自動的に検出しない Windows の他のモダンなターミナル環境では、 ANSICON="on" という適切な環境変数を設定することで、 ANSICON のインストールを「偽装」することができます。
シンタックスハイライトに使う色はカスタマイズできます。Django には 3 つのカラーパレットが同梱されています：
\ndark, 黒い背景に白いテキストを表示する端末に適しています。これはデフォルトのパレットです。
light, これは白い背景に黒いテキストを表示する端末に適しています。
nocolor, これはシンタックスハイライトを無効にします。
パレットを選択するには DJANGO_COLORS 環境変数を設定して使用したいパレットを指定します。例えば、UnixやOS/XのBASHシェルで light パレットを指定するには、ターミナルで以下のように実行します：
export DJANGO_COLORS="light"\n使用する色をカスタマイズすることもできます。Django は色が使われる役割（ロール）をいくつか指定しています：
\nerror - 主なエラー。
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 - マイグレーション名。
これらの各ロールには、以下のリストから特定の前景色と背景色を割り当てることができます：
\nblack
red
green
yellow
blue
magenta
cyan
white
これらの色はそれぞれ、以下の表示オプションを使って変更できます：
\nbold
underscore
blink
reverse
conceal
色の指定は、次のいずれかのパターンに従います：
\nrole=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"\nこれを指定すると、エラーは青地に黄色の点滅で表示され、通知はマゼンタで表示されます。それ以外の色の役割には色を付けません。
\n色はベースパレットを拡張して指定することもできます。色指定にパレット名を入れると、そのパレットが意味するすべての色が読み込まれます。つまり：
\nexport DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"\nこれを指定すると、light カラーパレットのすべての色の使用が指定されますが、error と notice の色は指定どおりにオーバーライドされます。
\nBash シェルを使用している場合は、Django bash 補完スクリプトのインストールを検討してください。スクリプトは Django のソース配布元の extras/django_bash_completion にあります。このスクリプトを使うと、django-admin と manage.py コマンドで tab キーによる補完が有効になります。使い方を説明すると、
まず、django-admin とタイプします。
[TAB] キーをクリックし、利用できるオプション一覧を表示します。
sql とタイプし、[TAB] キーを押すと、名前が sql で始まるオプション一覧が表示されます。
独自のカスタムアクションを追加したい場合は、カスタム django-admin コマンドの作り方 を読んでください。
\nstartproject, startapp, optimizemigration, makemigrations, squashmigrations によって作成された Python ファイルは、 black コマンドが PATH にあれば、それを使ってフォーマットされます。
もし black がグローバルにインストールされているが、現在のプロジェクトで使用したくない場合は、 PATH を明示的に設定できます：
PATH=path/to/venv/bin django-admin makemigrations\nstdout を使用するコマンドでは、必要に応じて出力を black にパイプできます：
django-admin inspectdb | black -\nコードから管理コマンドを呼び出すには call_command() を使います。
name呼び出すコマンドの名前またはコマンド・オブジェクト。オブジェクトがテストに必要でない限り、名前を渡すことが望ましいです。
\n*argsコマンドが受け付ける引数のリスト。引数は引数パーサに渡されるので、コマンドラインと同じスタイルで使用できます。たとえば、call_command('flush', '--verbosity=0') のようにします。
**optionsコマンドラインで受け付ける名前付きオプション。オプションは引数パーサを起動することなくコマンドに渡されるため、正しい型を渡す必要があります。例えば、call_command('flush', verbosity=0) (ゼロは文字列ではなく整数でなければなりません)。
例:
\nfrom django.core import management\nfrom django.core.management.commands import loaddata\n\nmanagement.call_command("flush", verbosity=0, interactive=False)\nmanagement.call_command("loaddata", "test_data", verbosity=0)\nmanagement.call_command(loaddata.Command(), "test_data", verbosity=0)\n上の interactive オプションのように、引数を取らないコマンドオプションはキーワードとして True または False で渡されることに注意してください。
名前付き引数は、以下の構文のいずれかを使って渡すことができます：
\n# Similar to the command line\nmanagement.call_command("dumpdata", "--natural-foreign")\n\n# Named argument similar to the command line minus the initial dashes and\n# with internal dashes replaced by underscores\nmanagement.call_command("dumpdata", natural_foreign=True)\n\n# `use_natural_foreign_keys` is the option destination variable\nmanagement.call_command("dumpdata", use_natural_foreign_keys=True)\nコマンドオプションの中には、 djangoo-admin や manage.py の代わりに call_command() を使用すると異なる名前になるものがあります。たとえば、 django-admin createsuperuser --no-input は call_command('createsuperuser', interactive=False) となります。 call_command() で使用するキーワード引数名を調べるには、コマンドのソースコードで parser.add_argument() に渡される dest 引数を確認してください。
複数のオプションを取るコマンドオプションは、リストで渡します：
\nmanagement.call_command("dumpdata", exclude=["contenttypes", "auth"])\ncall_command() 関数の戻り値は、コマンドの handle() メソッドの戻り値と同じです。
すべてのコマンドは stdout と stderr オプションをサポートしているので、標準出力やエラーのストリームはリダイレクトできます。例えば、次のように書くことができます：
with open("/path/to/command_output", "w") as f:\n management.call_command("dumpdata", stdout=f)\n