django-admin コマンドの作り方Link to this heading#manage.py を用いることで独自のアクションを登録する事ができます。例として、あなたが配布している Django アプリケーションに manage.py アクションを追加したくなったとします。このドキュメントでは、このチュートリアル で作成した polls アプリケーションに独自の closepoll コマンドを追加します。
独自のコマンドを追加するためには、 management/commands ディレクトリをアプリケーションに追加してください。Djangoは、そのディレクトリ内のアンダーバーで始まらないPythonモジュールすべてを manage.py コマンドに登録します。例えば:
polls/\n __init__.py\n models.py\n management/\n __init__.py\n commands/\n __init__.py\n _private.py\n closepoll.py\n tests.py\n views.py\nこの例では、closepoll コマンドは polls アプリケーションを INSTALLED_APPS に含むプロジェクト全てで利用できるようになります。
_private.py モジュールは管理コマンドとして利用できません。
closepoll.py モジュールには一つだけ満たすべき要件があります。それは、 BaseCommand クラスもしくはその サブクラス の一つを継承した Command クラスを定義することです。
コマンドを実装するには、polls/management/commands/closepoll.py を以下のように編集してください:
from django.core.management.base import BaseCommand, CommandError\nfrom polls.models import Question as Poll\n\n\nclass Command(BaseCommand):\n help = "Closes the specified poll for voting"\n\n def add_arguments(self, parser):\n parser.add_argument("poll_ids", nargs="+", type=int)\n\n def handle(self, *args, **options):\n for poll_id in options["poll_ids"]:\n try:\n poll = Poll.objects.get(pk=poll_id)\n except Poll.DoesNotExist:\n raise CommandError('Poll "%s" does not exist' % poll_id)\n\n poll.opened = False\n poll.save()\n\n self.stdout.write(\n self.style.SUCCESS('Successfully closed poll "%s"' % poll_id)\n )\n新たに作成したカスタムコマンドは python manage.py closepoll <poll_ids> と実行する事で利用できます。
handle() メソッドは一つ以上の poll_ids を受け取り、それぞれに対応した poll.opened を False にセットします。もしコマンドの利用者が存在しない poll を指定した場合、CommandError 例外が発生します。poll.opened 属性は元の チュートリアル には存在しないので、この例では polls.models.Question モデルに追加しました。
上記の closepoll は、追加のコマンドラインオプションを受け入れることで、投票を閉じる代わりに削除するように簡単に変更できます。これらのカスタムオプションは、次のように add_arguments() メソッドで追加できます:
class Command(BaseCommand):\n def add_arguments(self, parser):\n # Positional arguments\n parser.add_argument("poll_ids", nargs="+", type=int)\n\n # Named (optional) arguments\n parser.add_argument(\n "--delete",\n action="store_true",\n help="Delete poll instead of closing it",\n )\n\n def handle(self, *args, **options):\n # ...\n if options["delete"]:\n poll.delete()\n # ...\nThe option (delete in our example) is available in the options dict\nparameter of the handle method. See the argparse Python documentation\nfor more about add_argument usage.
独自のコマンドラインオプションを追加できるのに加え、管理コマンド に定義された --verbosity や --traceback といったオプションも標準で利用できます。
デフォルトでは、管理コマンドは現在アクティブなロケールで実行されます。
\n何らかの理由でカスタム管理コマンドをアクティブなロケールなしで実行する必要がある (たとえば、翻訳されたコンテンツがデータベースに挿入されないようにしたい) 場合は、 handle() メソッドで @no_translations デコレータを使用して翻訳を無効にします。
from django.core.management.base import BaseCommand, no_translations\n\n\nclass Command(BaseCommand):\n ...\n\n @no_translations\n def handle(self, *args, **options): ...\n翻訳の非アクティブ化には構成設定へのアクセスが必要なので、構成設定なしで機能するコマンドにデコレータを使用することはできません。
\nカスタム管理コマンドのテストに関する情報は テストに関するページ で得ることができます。
\nDjangoは、ビルトインコマンドを読み込んだ後に INSTALLED_APPS を逆順に検索してコマンドを登録します。この検索の際に、すでに登録済みのコマンド名と重複したコマンド名が見つかった場合、新しく見つかったコマンドで最初に見つけたコマンドをオーバーライドします。
別の言い方をすると、コマンドをオーバーライドするためには、新しいコマンドは、オーバーライドするコマンドと同じ名前でなければなりません。そして、そのアプリは、INSTALLED_APPS で、オーバーライドするコマンドのアプリよりも前にある必要があります。
意図せずオーバーライドされたサードパーティアプリからの管理コマンドは、オーバーライドされたコマンドの Command をインポートするプロジェクトのアプリ（INSTALLED_APPS でサードパーティアプリの前に注文） の1つで新しいコマンドを作成することにより、新しい名前で使用可能にできます。
全ての管理コマンドの派生元となる基底クラス。
\nコマンドライン引数を解析し、それに対してどのコードを呼び出すかを決定するすべてのメカニズムにアクセスしたい場合は、このクラスを使用してください。そのような動作を変更する必要がない場合は、 サブクラス のいずれかを使用することを検討してください。
\nBaseCommand クラスのサブクラス化には handle() メソッドの実装が必要です。
全ての属性は派生クラスでセットでき、BaseCommand クラスの サブクラス で利用可能です。
コマンドに関する短い説明。ユーザーが python manage.py help <command> を実行することでヘルプメッセージとして表示されます。
If your command defines mandatory positional arguments, you can customize\nthe message error returned in the case of missing arguments. The default is\noutput by argparse ("too few arguments").
コマンドが SQL 文を出力するかどうかを決めるブール値。True の場合、出力文が自動的に BEGIN; と COMMIT; で囲まれます。デフォルトの値は False です。
Boolean。True の場合、ディスク上に存在する一連のマイグレーション定義がデータベース上に保存されたマイグレーション定義とマッチしない場合に警告を出力します。この警告はコマンドの実行を停止させる物ではありません。デフォルトの値は False です。
例えば [Tags.staticfiles, Tags.models] のようなタグのリストやタプル。 指定したタグに登録された システムチェックは、コマンドを実行する前にエラーがないかチェックされます。 '__all__' を使用することで、すべてのシステムチェックを実行するように指定することができます。デフォルトでは '__all__' に設定されています。
stdout や stderr を記述した際にカラー出力を補助するインスタンス変数です。以下の利用例を参照ください:
self.stdout.write(self.style.SUCCESS("..."))\nカラーパレットの調整と利用可能なスタイルについては シンタックスカラーリング を参照してください (このセクションに記述されている "roles" のアルファベットを大文字にすると利用できます)。
\n--no-color オプションを渡してコマンドを実行した場合、全ての self.style() 呼び出しはオリジナルのカラー分けされていない出力を行います。
ヘルプ出力で抑制するデフォルトのコマンドオプション。これは、オプション名のセットでなければなりません（例：'--verbosity'）。抑制されたオプションのデフォルト値はそのまま渡されます。
\nBaseCommand には、いくつかのオーバーライド可能なメソッドが含まれています。しかし、handle() メソッドだけは、実装する必要があります。
CommandParser インスタンスを返します。これは ArgumentParser サブクラスで、Django用にいくつかカスタマイズされています。
このメソッドをオーバーライドし、 ArgumentParser パラメータの kwargs を使って super() を呼び出すことでインスタンスをカスタマイズできます。
コマンドに渡されたコマンドライン引数を操作するパーサーを追加するためのエントリポイントです。カスタム管理コマンドが受け取る位置引数およびオプション引数を追加するためにはこのメソッドをオーバーライドする必要があります。直接 BaseCommand を継承している場合は super() の呼び出しは必要ありません。
Djangoのバージョンを返します。これはすべての組み込みDjangoコマンドに対して正しいはずです。 ユーザー指定のコマンドは、このメソッドをオーバーライドして独自のバージョンを返すことができます。
\nコマンドを実行し、必要とされた場合(requires_system_checks 属性によって設定可能)システムチェックを行います。コマンドが CommandError 例外を発生させた場合は、実行を中断して stderr に出力します。
コマンドにおける実際の処理内容。サブクラスはこのメソッドを実装しなければなりません。
\nstdout に出力される文字列を返すことができます (output_transaction が True の場合、文字列は BEGIN; と COMMIT; で挟まれて出力されます)。
潜在的な問題のために Django プロジェクト全体を検証するシステムチェックフレームワークを利用します。致命的な問題は CommandError 例外を発生し、警告は stderr への出力、重要でない通知は stdout への出力となります。
app_configs および tags が共に None であった場合、デプロイメントとデータベース関連のチェック以外の全てのシステムチェックが実行されます。tags はチェックタグ、例えば compatibility あるいは models 等、のリストとなります。
また、include_deployment_checks=True を渡すとデプロイメントのチェックを行い、databases にデータベースエイリアスのリストを渡すとデータベース関連のチェックを行います。
requires_system_checks の値を tag 引数に変換するなど、 check() の呼び出しに引数を提供します。
このメソッドをオーバーライドすると、 check() に渡される値が変更されます。例えば、データベース関連のチェックを有効にするには、 get_check_kwargs() をオーバーライドします:
def get_check_kwargs(self, options):\n kwargs = super().get_check_kwargs(options)\n return {**kwargs, "databases": [options["database"]]}\nBaseCommand のサブクラスLink to this heading#一つ以上のインストールされたアプリケーションラベルを引数として受け取り、それぞれに対して何らかの処理を行う管理コマンド。
\nhandle() を実装する代わりに、サブクラスでは、アプリケーション毎に一度ずつだけ呼び出される handle_app_config() を実装する必要があります。
コマンドラインで渡されたアプリケーションラベル個々に対応している AppConfig のインスタンスである app_config に応じたコマンドの処理を行います。
コマンドラインで1つ以上の任意の引数（ラベル）を受け取り、それぞれに対して何かを行う管理コマンド。
\nサブクラスは、handle() を実装するのではなく、ラベルごとに1回呼び出される handle_label() を実装する必要があります。
コマンドに渡される任意引数について記述した文字列。この文字列はコマンドの使用法やエラーメッセージに利用します。デフォルトは 'label' です。
コマンドラインに渡された文字列である label に対応したコマンドの処理を行います。
管理コマンド実行中に発生した問題について示した例外クラス。
\nこの例外がコマンドラインコンソールからの管理コマンドの実行中に発生した場合、キャッチされて適切な出力ストリーム（つまり、stderr）に対して整形されたエラーメッセージに変換されます。そのため、コマンドの実行中に何かが間違っていることを示す場合は、この例外を（エラーの理にかなった説明とともに）発生させることを推奨します。任意で returncode 引数を受け入れて、sys.exit() で管理コマンドが終了する際の終了ステータスをカスタマイズできます。
call_command() を介して管理コマンドが実行された場合は、例外の捕捉をするかどうかは実装に依存します。