django-admin.py と manage.py

revision-up-to:7127 (0.97pre SVN)

django-admin.py は Django の管理タスクを行うためのコマンドライン ユーティリティです。このドキュメントでは django-admin.py の全ての 機能について説明します。

また、各 Django プロジェクトには manage.py が自動的に生成されます。 manage.py は django-admin.py に対する薄いラッパで、 django-admin.py に仕事を引き渡す前に以下の二つの処理を行います:

  • プロジェクトのパッケージを sys.path に追加します。
  • DJANGO_SETTINGS_MODULE 環境変数がプロジェクトの settings.py を指すように設定します。

Django を setup.py ユーティリティでインストールしていれば、 django-admin.py スクリプトはシステムパス上にあるはずです。システム パス上にない場合、 Python インストールディレクトリ上の site-packages/django/bin を探せば見つかるでしょう。 /usr/local/bin のようなパス上のどこかにシンボリックリンクを張って おくように勧めます。

Windows を使っていて、シンボリックリンクを張れない場合には、パスの通った場 所に django-admin.py をコピーするか、 PATH の設定値を ( マイコンピュータ(右クリック) - プロパティ - 詳細設定 - 環境変数 - システム環境変数 で) django-admin.py のインストールされ ている場所を指すように変更してください。

一般論として、一つの Django プロジェクトだけで作業しているなら、 manage.py を使う方が簡単といえるでしょう。 django-admin.py と DJANGO_SETTINGS_MODULE や --settings コマンドラインオプション を使えば、複数の Django 設定ファイルを切替えて操作できます。

このドキュメント内でのコマンドライン例では、一貫して django-admin.py を 使っていますが、実際には manage.py を使ってもかまいません。

使い方

django-admin.py <subcommand> [options]

manage.py <subcommand> [options]

subcommand には、このドキュメントで挙げているいずれかのサブコマンド を指定します。 options は省略可能で、このドキュメントで挙げている ゼロ個から複数個の利用可能なオプションをサブコマンドに与えます。

ランタイムヘルプを取得する

Django 0.96では、 django-admin.py --help を実行すると、利用できる全ての サブコマンドとオプションの詳細なリストの入ったヘルプメッセージを出力します。

開発版のDjangoでは、 django-admin.py --help を実行すると、利用できる全ての サブコマンドを出力します。 django-admin.py help <subcommand> を実行すると 与えられたサブコマンドで利用できるオプションの詳細なリストを出力します。

アプリケーションの名前

ほとんどのサブコマンドは appname のリストを引数にとります。 appname はモデルの入ったパッケージの名前です。例えば INSTALLED_APPS に mysite.blog を追加している場合、このアプリケーションの appname は blog です。

バージョンを表示する

django-admin.py --version を実行すると、使用しているDjangoのバージョンを表示します。

表示例:

0.95
0.96
0.97-pre-SVN-6069

利用可能なサブコマンド

adminindex <appname appname ...>

-指定した appname に対する admin-index テンプレート断片 (snippet) を出力し ます。

admin-index テンプレート断片は、 admin のインデクスページのルック&フイー ルをカスタマイズしたい場合に使って下さい。詳しくは チュートリアルその 2 を参照してください。

createcachetable <tablename>

データベースキャッシュバックエンドで使うための、 tablename という 名前のキャッシュテーブルを生成します。詳しくは cache のドキュメント を参照してください。

dbshell

DATABASE_ENGINE 設定に指定されたデータベースエンジンに対し、 DATABASE_USER および DATABASE_PASSWORD 等の設定に従ってコマンドライ ンクライアントを起動します。

  • PostgreSQL の場合には psql を実行します。
  • MySQL の場合には mysql を実行します。
  • SQLite の場合には sqlite3 を実行します。

このコマンドはプログラムが PATH 上にあると想定しているので、単純に プログラム名で呼び出したとき (psql, mysql, sqlite3) に見つかる プログラムを使います。プログラムの場所を手動で指定する方法はありません。

diffsettings

現在の設定ファイルと Django のデフォルト設定との差分を表示します。

デフォルト設定にない設定の末尾には "###" を追加します。例えば、 デフォルト設定には ROOT_URLCONF 変数がないので、 diffsettings の出力中では ROOT_URLCONF の末尾に "###" が付きます。

デフォルト設定の完全なリストを見たければ、 django/conf/global_settings.py にある Django のデフォルト設定を参照して ください。

dumpdata <appname appname ...>

指定したアプリケーション (複数指定可) に関係した全てのデータをデータベース から取り出し、標準出力に出力します。

アプリケーション名を指定しなかった場合、インストール済みのアプリケーション 全てのデータをダンプします。

dumpdata の出力は loaddata の入力に使えます。

dumpdata は、ダンプするレコードを取り出すときに、モデルのデフォルトマネ ジャを使います。デフォルトマネジャに カスタムマネジャ を使っていて、 カスタムマネジャ内でレコードの一部をフィルタしていると、一部のオブジェクト がダンプされなくなるので注意してください。

--format

デフォルトでは、 dumpdata の形式は JSON で出力されますが、 --format オプションを使って別の形式を指定することもできます。現在サポート しているフォーマットは シリアライズ形式一覧 に列挙されています。

使用例:

django-admin.py dumpdata --format=xml

--indent

デフォルトでは、 dumpdata はすべてのデータを1行で出力します。これは 人間にとって読みやすくありません。出力を整形するためのインデント幅のスペース数の 指定に --indent オプションを使うことができます。

使用例:

django-admin.py dumpdata --indent=4

flush

データベースを syncdb 直後の状態に戻します。全てのデータがデータベースから 除去され、同期直後に呼び出される全てのハンドラが再度実行されます。また、 initial_data フィクスチャも再インストールされます。

開発版の Django では、このコマンドの動作仕様は変更されています。以前は、こ のコマンドはデータベース上のテーブルを (INSTALLED_APPS に登録されている モデルに関係しているかどうかに関わらず) 全て 消去していましたが、開発版 では、 INSTALLED_APPS で有効化しているモデルのテーブルだけを消去するよ うになりました。

--noinput

ユーザプロンプトでの "Are you sure?" のような確認メッセージの出力の抑制には --noinput オプションを使います。対話を必要とせずに django-admin.py を実行する自動化されたスクリプトで役に立ちます。

--verbosity

django-admin.py の通知情報やデバッグ情報のコンソールへの出力量を指定する には --verbosity を使います。

  • 0 だと、何も出力しません。
  • 1 だと、通常の出力 (デフォルト) です。
  • 2 だと、詳細に出力します。

使用例:

django-admin.py flush --verbosity=2

inspectdb [dbname]

DATABASE_NAME 設定で指定されたデータベース上のテーブルに対するイントロ スペクションを行い、Django モデルモジュール (models.py) を標準出力に出 力します。

古いデータベースを持っていて、それを Django で使いたい場合に使ってくだ さい。スクリプトはデータベースを調べ、データベース内の各テーブルに対す るモデルを生成します。

想像の通り、生成されるモデルは、テーブルの各フィールド名に対応する属性 を持ちます。 inspectdb はフィールド名の出力に際して以下のようないく つかの特殊なケースを持っているので注意して下さい:

  • 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 を使っている場合、イントロスペクションで主キーを自動的 に決定し、必要な場所に primary_key=True を追加します。

inspectdb は PostgreSQL, MySQL および SQLite で動作します。外部キー の検出は PostgreSQL と一部の MySQL テーブル形式でのみ有効です。

loaddata <fixture fixture ...>

名前付きのフィクスチャを探し、その中身をデータベースにロードします。

フィクスチャ (fixture) とは、データベースに入れるデータをシリアライズして 格納したファイル群を指します。各フィクスチャファイルには固有の名前を付けら れますが、ある名前のフィクスチャを複数のディレクトリに入れても構いませんし、 複数のアプリケーション内に配置してもかまいません。

Django は以下の 3 種類の場所からフィクスチャを探します:

  1. インストール済みの各アプリケーションの fixtures ディレクトリ
  2. FIXTURE_DIRS 設定に指定したディレクトリ
  3. fixture に直接指定したパス

Django は上記の場所に見つかった全てのフィクスチャファイルの中から、指定した フィクスチャ名と一致するファイルをロードします。

フィクスチャ名にファイル拡張子を指定すると、指定した型のフィクスチャだけが ロードされます。例えば:

django-admin.py loaddata mydata.json

のようにすると、 mydata という名前の JSON フィクスチャだけがロードされ ます。フィクスチャの拡張子は、 (json や xml のように) シリアライザ の登録名に対応していなければなりません。

拡張子を省略すると、 Django は全ての形式にフィクスチャを対象にフィクスチャ ファイルを検索します。例えば:

django-admin.py loaddata mydata

のようにすると、 mydata という名前の全てのフィクスチャを探します。フィ クスチャディレクトリに mudata.json という名前のファイルがあれば、 JSON 形式のフィクスチャとしてロードされます。同じ名前で別のフィクスチャ形式のも のが見つかった場合 (例えば、 mydata.json と mydata.xml が同じディレ クトリ下にあった場合)、フィクスチャのインストールは中止され、それまでに loaddata によってロードされたデータは全てデータベースから削除されます。

フィクスチャの名前にはディレクトリ名を入れても構いません。ディレクトリ部分 を指定すると、各検索パスに追加されます。例えば:

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

とすると、インストール済みの各アプリケーションのディレクトリ <appname> について <appname>/fixtures/foo/bar/mydata.json を、 FIXTURE_DIRS の各ディレクトリ <dirname> について <dirname>/foo/bar/mydata.json を、そして相対パス foo/bar/mydata.json を探します。

フィクスチャファイルの処理順は決まっていませんが、全てのフィクスチャのイン ストールは単一のトランザクションで行われるため、あるフィクスチャが別のフィ クスチャに対する参照を持っていてもかまいません。データベースバックエンドが 行レベルの制約 (row-level constraint) をサポートしているばあい、制約はトラ ンザクションの最後にチェックされます。

dumpdata コマンドを使うと、 loaddata の入力データを生成できます。

MySQL とフィクスチャ

残念ながら、MySQL は Django のフィクスチャに関する全ての機能を利用でき るわけではありません。 MyISAM を使っている場合、 MySQL はトランザクショ ンや制約をサポートしていないので、複数のフィクスチャファイルに対するロー ルバックを行えず、フィクスチャデータの検証も行えません。一方、 InnoDB を使っている場合、データファイル間で前方参照を行えません。 MySQL は行制 約のチェックをトランザクションコミット直前まで遅延するためのメカニズム を備えていないからです。

--verbosity

django-admin.py のメッセージの通知やデバッグ情報のコンソールへの出力量を 指定するには --verbosity を使います。

  • 0 だと、何も出力しません。
  • 1 だと、通常の出力 (デフォルト) です。
  • 2 だと、詳細に出力します。

使用例:

django-admin.py loaddata --verbosity=2

reset <appname appname ...>

指定した appname に対して sqlreset と同じ操作を実行します。

--noinput

ユーザプロンプトでの "Are you sure?" のような確認メッセージの出力の抑制には --noinput オプションを使います。対話を必要とせずに django-admin.py を実行する自動化されたスクリプトで役に立ちます。

runfcgi [options]

FastCGI プロトコルをサポートする Web サーバ向けの一連の FastCGI プロセス群 を起動します。詳しくは FastCGI による運用 を参照してくださ い。 Python の FastCGI インタフェースモジュールである flup が必要です。

runserver [optional port number, or ipaddr:port]

ローカルマシン上に軽量な開発用ウェブサーバを立ち上げます。デフォルトで は、サーバは IP アドレス 127.0.0.1、ポート番号 8000 で動作します。 IP アドレスやポート番号は明示的に指定できます。

このスクリプトを通常ユーザの権限下で実行した場合 (そうするように勧めま す)、ポート番号を低い値にできないかもしれません。値の低いポート番号は スーパユーザ (root) 用に予約されているからです。

開発用サーバをプロダクションサーバとして使ってはなりません。 開発用サーバはセキュリティ検査もパフォーマンステストも行われていません (我々が目指しているのは Web フレームワークの開発であり、このサーバを改良し て運用環境でも利用できるようにするのは Django プロジェクトの目的とするとこ ろではありません。)

開発サーバはリクエストを受け付ける度に、必要に応じて自動的に Python コー ドをリロードします。このため、コードの変更を反映させるためにいちいちサー バを際起動しなくてもよくなっています。

サーバの起動時や、サーバの稼働中に Python コードを変更した場合、開発用 サーバはインストールされている全てのモデルを自動的に検証します (後述の validate オプションを参照してください)。検証時にエラーが見つかった場 合、エラーは標準出力に出力されますが、サーバは停止しません。

ポート番号を別々にしているかぎりいくつでもサーバを起動できます。 django-admin.py runserver を複数回起動するだけです。

デフォルトの IP アドレスである 127.0.0.1 は、ネットワーク上の他のマシ ンからは利用できません。開発サーバをネットワーク上の他のマシンから 見えるようにするには、サーバホスト固有の IP アドレス (例えば 192.168.2.1) または 0.0.0.0 を使って下さい。

--adminmedia

Django 管理インタフェース用の CSS や JavaScript ファイルを探す場所を Django に 教えるには --adminmedia オプションを使います。通常、これらのファイルは Django のソースツリーから探索されて配信されるようになっていますが、自作のサイト 用に変更を加えた CSS や JavaScript を指定したい場合には、このオプションを使いま す。

使用例:

django-admin.py runserver --adminmedia=/tmp/new-admin-style/

--noreload

自動リロード機能の使用を無効にするには --noreload オプションを使います。 これが意味するところは、サーバの稼働中にいかなる Python コードの変更も検知 せず 既にメモリ上に読み込まれている Python モジュールが利用されます。

異なる IP アドレスとポート番号を使用する例

IP アドレス 127.0.0.1、ポート番号 8000:

django-admin.py runserver

IP アドレス 1.2.3.4、ポート番号 8000:

django-admin.py runserver 1.2.3.4:8000

IP アドレス 127.0.0.1、ポート番号 7000:

django-admin.py runserver 7000

IP アドレス 1.2.3.4、ポート番号 7000:

django-admin.py runserver 1.2.3.4:7000

開発用サーバで静的なファイルを提供する

デフォルトでは、開発用サーバはサイト用の静的ファイル (CSSファイル、画像、 MEDIA_URL 下のファイルなど) を全く提供しません。 Django に静的メディ アを提供させたければ、 静的なファイルの提供方法 を参照してくださ い。

自動リロードを切る

開発サーバに実行中にコードを自動リロードさせたくなければ、以下のように --noreload オプションを使ってください:

django-admin.py runserver --noreload

shell

Python の対話インタプリタを起動します。

IPython がインストールされている場合、Django は IPython を使おうとします。 IPython がインストールされていて、かつ「普通の」インタプリタを使いたいのな ら、以下のように --plain オプションを使って下さい:

django-admin.py shell --plain

sql <appname appname ...>

指定した appname の CREATE TABLE SQL 文を出力します。

sqlall <appname appname ...>

指定した appname の CREATE TABLE および初期カスタム SQL の発行、データ入力 のための SQL 文を出力します。

初期カスタム SQL の指定方法は sqlcustom の説明を参照してください。

sqlclear <appname appname ...>

指定した appname の DROP TABLE SQL 文を出力します。

sqlcustom <appname appname ...>

指定した appname のカスタム SQL 文を出力します。

このコマンドは、指定した各アプリケーションのモデルについて、 <appname> をアプリケーションの名前、 <modelname> をモデルの名前を全て小文字にした 文字列として、 <appname>/sql/<modelname>.sql という名前のファイルを探し ます。例えば、 news というアプリケーションで Story というモデルが定 義されていれば、 sqlcustom は news/sql/story.sql というファイルを探 して読みだし、その内容をこのコマンドの出力の末尾に追加します。

各 SQL ファイルには、有効な SQL を入れることになっています。 SQL ファイルの 内容は、モデルのテーブル生成文を全て実行した後に、データベースに直接パイプ されます。テーブルに対して変更を加えたり、 SQL 関数をデータベースに組み込む には、この SQL フックを使ってください。

sqlflush

flush コマンドによって実行されるのと等価な SQL 文を出力します。

sqlindexes <appname appname ...>

指定したアプリケーションに対する CREATE INDEX SQL 文を出力します。

sqlreset <appname appname ...>

指定した appname に対する DROP TABLE SQL 文を出力し、 その後で CREATE TABLE SQL 文を出力します。

sqlsequencereset <appname appname ...>

指定した appname のシークエンスをリセットするためのSQL 文を出力します。

詳しくは http://simon.incutio.com/archive/2004/04/21/postgres を参照し てください。

startapp <appname>

現在のディレクトリに、 appname に指定した名前の Django アプリケーショ ンディレクトリ階層を作成します。

startproject <projectname>

現在のディレクトリに、 projectname に指定した名前の Django プロジェク トディレクトリ階層を作成します。

syncdb

INSTALLED_APPS に登録されており、まだテーブルを作成していないアプリケー ション全てのテーブルを作成します。

このコマンドは、新たなアプリケーションをプロジェクトに追加し、データベース にインストールしたい場合に使って下さい。アプリケーションには、 Django に付 属しているアプリケーションで、デフォルトで INSTALLED_APPS に入っている ものも含みます。新たなプロジェクトを開始する際には、このコマンドを実行して デフォルトのアプリケーションをインストールする必要があります。

syncdb は既存のテーブルを置き換えません

syncdb は、インストールされていないモデルのテーブルしか作成しません。 すでにインストールされているモデルクラスに変更を行っても、それに合わせる ように ALTER TABLE を発行することは 決してありません 。モデルクラ スやデータベーススキーマに対する変更には、何らかの形であいまいな部分があ るものです。そのあいまいな部分に対して、 Django どのように変更を適用すべ きか正しく判断せねばならないとすれば、変更の過程で重要なデータが失われる というリスクが生まれてしまいます。

モデルに変更を適用した後、変更に合わせてデータベーステーブルも置き換えた いのなら、 sql コマンドを使って新たな SQL を出力し、既存のテーブルス キーマと比較して、手動で変更を適用してください。

django.contrib.auth アプリケーションをインストールした場合には、 syncdb はスーパユーザを作成するか尋ねます。

syncdb はまた、 initial_data という名前で、適切な拡張子 (json や xml など) のフィクスチャを探してインストールします。フィクスチャデー タファイルの詳細は loaddata のドキュメントを参照してください。

--verbosity

django-admin.py の通知情報やデバッグ情報のコンソールへの出力量を指定する には --verbosity を使います。

  • 0 だと、何も出力しません。
  • 1 だと、通常の出力 (デフォルト) です。
  • 2 だと、詳細に出力します。

使用例:

django-admin.py syncdb --verbosity=2

--noinput

ユーザプロンプトでの "Are you sure?" のような確認メッセージの出力の抑制には --noinput オプションを使います。対話を必要とせずに django-admin.py を実行する自動化されたスクリプトで役に立ちます。

test

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

--noinput

ユーザプロンプトでの "Are you sure?" のような確認メッセージの出力の抑制には --noinput オプションを使います。対話を必要とせずに django-admin.py を実行する自動化されたスクリプトで役に立ちます。

--verbosity

django-admin.py の通知情報やデバッグ情報のコンソールへの出力量を指定する には --verbosity を使います。

  • 0 means no input.
  • 1 means normal input (default).
  • 2 means verbose input.

使用例:

django-admin.py test --verbosity=2

testserver <fixture fixture ...>

開発版の Django で新たに登場した機能です

指定したフィクスチャを使って、 (runserver と同様に) 開発用サーバを起動 します。

例えば、次のコマンド:

django-admin.py testserver mydata.json

を実行すると、以下のようなステップを実行します:

  1. Django アプリケーションのテスト 手順に従って、テストデータベース を生成します。
  2. 指定したフィクスチャを使ってテストデータベースに値を入れます (フィク スチャの説明は loaddata ドキュメントを参照してください)。
  3. 生成したテストデータベースを使って (runserver と同様に) 開発サー バを実行します。

testserver が便利な局面はいくつかあります:

  • 特定のフィクスチャデータに対するビューの動作を調べるための ユニットテスト を書いている際に、ブラウザでの表示を手動で調べるの に testserver を使えます。
  • Django アプリケーションを開発していて、「無垢の状態の」データベースを 使って操作してみたいとしましょう。データベースを (前述の dumpdata コマンドを使って) フィクスチャとしてダンプしておき、 testserver を使って Web アプリケーションを実行すれば、アプリケーション上でどんな 操作を行っても、変更はテストデータベースにしか加えられないので、好き にデータベースを「汚せ」ます。

runserver は動作中に Python のソースコード上に加えられた変更を自動的に 検出しますが、 testserver は検出しません。ただし、テンプレートへの変更 は検出します。

--addrport [port number or ipaddr:port]

IP アドレスやポート番号を 127.0.0.1:8000 から変更するには、 --addrport を使います。この値は、 runserver サブコマンドの引数と同じ形式で指定し、 意味も同じです。

テストサーバをポート 7000 で起動し、 fixture1 および fixture2 のテ ストを実施するには、以下のようにします:

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

(上の二つのコマンドは互いに等価です。オプションはフィクスチャを指定するため の引数の前にきても後ろに来てもかまいません。)

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

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

--verbosity

django-admin.py の通知情報やデバッグ情報のコンソールへの出力量を指定する には --verbosity を使います。

  • 0 だと、何も出力しません。
  • 1 だと、通常の出力 (デフォルト) です。
  • 2 だと、詳細に出力します。

使用例:

django-admin.py testserver --verbosity=2

validate

インストールされている (INSTALLED_APPS に登録されている) 全てのモ デルを検証 (validate) し、エラーがあれば標準出力に出力します。

デフォルトのオプション

Although some subcommands may allow their own custom options, every subcommand allows for the following options:

--pythonpath

使用例:

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

指定したファイルシステムパスを Python の import 検索パス に追加 します。このオプションを指定しない場合、 django-admin.py は環境変 数 PYTHONPATH を使います。

manage.py は Python パスをきちんと設定してくれるので、このオプション は必要ありません。

--settings

使用例:

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

管理対象のプロジェクトの設定モジュールを明示的に指定します。設定モジュー ルは Python のパッケージ表現構文、すなわち "mysite.settings" のような形式で 指定します。このオプションを指定しない場合、 django-admin.py は環境変数 DJANGO_SETTINGS_MODULE を使います。

manage.py はデフォルトで現在のプロジェクトの settings.py を使うので、 通常はこのオプションは必要ありません。

その他のからくり

シンタクスの色づけ

SQL 文を標準出力に出力する django-admin.py / manage.py コマンドは、 端末が ANSI カラー出力をサポートする場合にはコードを色づけして表示します。 ただし、出力を別のプログラムにパイプしている場合には色づけを行いません。

bash での補完

bash シェルを使っているのなら、 Django の bash 補完スクリプトのインストール を検討してみてください。スクリプトは Django 配布物の extras/django_bash_completion にあります。 bash 補完機能を使うと、 django-admin.py および manage.py コマンドをタブ補完できるようになり ます。例えば:

  • django-admin.py とタイプします。
  • [TAB] を押すと、利用可能な全てのオプションを表示します。
  • sql とタイプして [TAB] を押すと、 sql で始まる全てのオプショ ンを表示します。

アクションを自作する

開発版の Django で新たに登場した機能です

アプリケーションごとに独自のアクションを定義して、 manage.py で使える ようにできます。例えば、配布したいアプリケーションの中に、 manage.py ア クションを追加したい場合があるとします。

アクションを追加するには、アプリケーション内に management/commands ディ レクトリを作成します。このディレクトリ内のモジュールは、 manage.py の実 行時に呼び出せるアクションとして自動的に検出されます:

blog/
    __init__.py
    models.py
    management/
        __init__.py
        commands/
            __init__.py
            explode.py
    views.py

上の例では、 blog アプリケーションを settings.INSTALLED_APPS に登録 してあるプロジェクトで explode というコマンドを使えるようになります。

コマンドモジュールの必須の条件として、 explode.py は django.core.management.base.BaseCommand を拡張した Command という名 前のクラスを定義していなければなりません。

自作のコマンドを定義する詳しい方法は、既存の django-admin.py コマンドの ソースコードを参照してください。ソースは /django/core/management/commands にあります。