django-admin.py と manage.py

revision-up-to:11321 (1.1) unfinished

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

また、各 Django プロジェクトには manage.py が自動的に生成されます。 manage.pydjango-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.pyDJANGO_SETTINGS_MODULE--settings コマンドラインオプション を使えば、複数の Django 設定ファイルを切替えて操作できます。

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

使い方

django-admin.py <subcommand> [options]
manage.py <subcommand> [options]

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

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

--help

django-admin.py help を実行すると、利用できる全てのサブコマンドを出力し ます。 django-admin.py help <subcommand> を実行すると、指定のサブコマン ドで利用できるオプションの詳細なリストを出力します。

アプリケーションの名前

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

バージョンを表示する

--version

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

表示例:

0.95
0.96
0.97-pre-SVN-6069

デバッグ出力を表示する

--verbosity <amount>

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

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

利用可能なサブコマンド

cleanup

Django 1.0 で新たに登場しました: リリースノートを参照してください

cron によるジョブとして実行したり、直接実行したりして、データベースから 古いデータ (現時点では、有効期限の切れたセッションのみ) を消去します。

compilemessages

Django 1.0 で新たに登場しました: 1.0 以前は “bin/compile-message.py” コマンドでした。

makemessages で作成した .po ファイルをコンパイルして、組み込みの gettext サポートで使えるようにします。詳しくは topics-i18n を参照し てください。

–locale

処理したいロケールを指定するには --locale または -l オプションを使 います。指定しなければ、全てのロケールを処理します。

使い方:

django-admin.py compilemessages --locale=br_PT

createcachetable

django-admin.py createcachetable <tablename>

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

createsuperuser

django-admin.py createsuperuser
Django 1.0 で新たに登場しました: リリースノートを参照してください

スーパユーザアカウント (全てのパーミッションを保有するユーザ) を作成します。 初期スーパユーザを syncdb の実行時以外の場所で作成したい場合や、プログ ラム上でスーパユーザアカウントを生成したい場合に便利です。

対話的に実行すると、 django-admin.py コマンドはスーパユーザアカウントの パスワードを入力するよう促します。非対話的に実行した場合、パスワードは設定 されず、パスワードを手動で設定するまで、作成されたスーパユーザはログインで きません。

--username
--email

新たに作成するアカウントのユーザ名と e-mail アドレスは、それぞれ コマンドラインの --username および --email 引数で指定できます。 どちらの引数も指定しなければ、 createsuperuser は対話モードでの実行時に 入力を促します。

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

dbshell

django-admin.py dbshell

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

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

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

diffsettings

django-admin.py diffsettings

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

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

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

dumpdata

django-admin.py dumpdata <appname appname appname.Model ...>

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

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

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

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

--exclude
Django 1.0 で新たに登場しました: リリースノートを参照してください

出力から、特定のアプリケーションに関するコンテンツを除外します。例えば、 auth アプリケーションのコンテンツを出力から除外したければ、以下のように 実行します:

django-admin.py dumpdata --exclude=auth

複数のアプリケーションを除外したければ、複数回 --exclude ディレクティブ を使います:

django-admin.py dumpdata --exclude=auth --exclude=contenttype
--format <fmt>

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

--indent <num>

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

Django 1.1 で新たに登場しました: リリースノートを参照してください

In addition to specifying application names, you can provide a list of individual models, in the form of appname.Model. If you specify a model name to dumpdata, the dumped output will be restricted to that model, rather than the entire application. You can also mix application names and model names.

flush

django-admin.py flush

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

--noinput

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

inspectdb

django-admin.py inspectdb

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 フィクスチャだけがロードされ ます。フィクスチャの拡張子は、 (jsonxml のように) シリアライザ の登録名に対応していなければな りません。

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

django-admin.py loaddata mydata

のようにすると、 mydata という名前の全てのフィクスチャを探します。フィ クスチャディレクトリに mudata.json という名前のファイルがあれば、 JSON 形式のフィクスチャとしてロードされます。

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

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 を探します。

フィクスチャファイルを処理する際、データはデータベースにそのまま保存され、 モデルごとに定義した save メソッドや pre_save シグナルは呼び出され ません。

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

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

Compressed fixtures

Fixtures may be compressed in zip, gz, or bz2 format. For example:

django-admin.py loaddata mydata.json

would look for any of mydata.json, mydata.json.zip, mydata.json.gz, or mydata.json.bz2. The first file contained within a zip-compressed archive is used.

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

MySQL とフィクスチャ

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

makemessages

Django 1.0 で新たに登場しました: 1.0 より前のバージョンでは、 bin/make-messages.py コマンドでした。

現在のディレクトリ以下にあるソースツリー全体を走査して、翻訳対象にマークさ れている文字列全てを取り出します。django のソースツリー上で行った場合には conf/locale 下に、プロジェクトやアプリケーションのソースツリー上で行っ た場合には locale 下にメッセージファイルを作成します。メッセージファイ ルに変更があった場合、 compilemessages でファイルをコンパイルして、組み 込みの gettext サポートで利用できるようにしてください。詳しくは i18n のドキュメント を参照してください。

–all

全ての言語のメッセージファイルを更新するには --all または -a を使っ てください。

使い方:

django-admin.py makemessages --all

–extension

メッセージを取り出す対象に含めるファイルの拡張子を指定するには --extension または -e オプションを使います(デフォルトは ”.html” で す)。

使い方:

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

複数の拡張子を指定するには、カンマで区切るか、 --extension-e を複数使います:

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

–locale

処理したいロケールを指定するには --locale または -l オプションを使 います。

使い方:

django-admin.py makemessages --locale=br_PT

–domain

メッセージファイルのドメインを変更するには --domain または -d オプ ションを使ってください。

現在サポートしているのは、以下のドメインです:

  • django: *.py ファイルと *.html ファイル (デフォルト)
  • djangojs: *.js ファイル

reset <appname appname ...>

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

–noinput

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

runfcgi [options]

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

runserver

django-admin.py runserver [port 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 モジュールが利用されます。

使用例:

django-admin.py runserver --noreload

異なる 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 に静的メディ アを提供させたければ、 静的なファイルの提供方法 を参照してください。

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 というモデルが定 義されていれば、 sqlcustomnews/sql/story.sql というファイルを探 して読みだし、その内容をこのコマンドの出力の末尾に追加します。

各 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 文を出力します。

Sequences are indexes used by some database engines to track the next available number for automatically incremented fields.

Use this command to generate SQL which will fix cases where a sequence is out of sync with its automatically incremented field data.

startapp <appname>

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

startproject <projectname>

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

--settings オプションを指定して django-admin.py を呼び出したときや、 環境変数 DJANGO_SETTINGS_MODULE が指定されていると、このコマンドを使え ません。 startproject を使いたければ、 --settings オプションを外し、 DJANGO_SETTINGS_MODULE を unset してください。

syncdb

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

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

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

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

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

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

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

–noinput

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

test

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

–noinput

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

testserver <fixture fixture ...>

Django 1.0 で新たに登場しました: リリースノートを参照してください

指定したフィクスチャを使って、 (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

validate

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

デフォルトのオプション

各々のサブコマンドの独自のオプションの他に、以下の共通のオプションがありま す:

–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 を使うので、 通常はこのオプションは必要ありません。

–traceback

使用例:

django-admin.py syncdb --traceback

デフォルトでは、 django-admin.py はエラーが起きるたびに簡単なエラーメッ セージを表示します。 --traceback を指定すると django-admin.py は 例外が送出された際に完全なスタックトレースを出力します。

–verbosity

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

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

使用例:

django-admin.py loaddata --verbosity=2

その他のからくり

シンタクスの色づけ

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 で始まる全てのオプショ ンを表示します。

アクションを自作するには、 アクションを自作する を参照し てください。