この記事では、Django での開発において、 settings.py などの設定ファイルを含むディレクトリの命名を何にするかについて私見を述べます。
これはあくまで私個人の私見であり、もしかすると一般論とは少し離れているかもしれませんがご了承ください。
一般的(と思われる)命名習慣
Djangoプロジェクトにおいて、settings.py
が含まれる設定ファイル群のフォルダの命名の例をいくつか挙げてみましょう。
プロジェクト名と同じ名前
- これが最も一般的な方法(だと思っています)
- 例えば、プロジェクト名が "myproject" の場合、フォルダ構造は以下のようになります
myproject/
├── manage.py
└── myproject/
├── __init__.py
├── settings.py
├── urls.py
└── wsgi.py
個人的な命名習慣
個人的には、 config を好んでつけています。
core を選択する場合もあります。
myproject/
├── manage.py
└── config/
├── __init__.py
├── settings.py
├── urls.py
└── wsgi.py
先ほどのディレクトリ構造と比べてどう思いますか?
myproject 以下には、さまざまなアプリケーションが追加されるはずです。
そのため、設定ファイルが myproject と同じ場合、紛らわしいのです。
myproject だとまだマシですが、 プロジェクト名が sales_management だったらどうですか?
sales_management がその下にあったら、実際の機能を含むアプリケーションと見分けがつかなくなってしまいますよね(私見)。
私個人としては、settings.py や urls.py なんてプロジェクトに属するチームメンバー皆が参照するものなので、明示的な名前をつけた方がいいに決まってる!と思っています。
config とか core は個人的にはすごくしっくりきます。
設定ファイルの分割
そして、一般的な Django プロジェクトでは、設定ファイルを分割することが通常のアプローチだと思います。
一般的な分割方法としては、ベース設定ファイルを作成し、各環境ごとの設定ファイルを別途用意する方法がよく採用されるのではないでしょうか。
具体的には、以下のような構成になると思います。
myproject/
├── manage.py
└── config/
├── __init__.py
├── settings/
│ ├── __init__.py
│ ├── base.py
│ ├── development.py
│ ├── staging.py
│ └── production.py
├── urls.py
└── wsgi.py
ベース設定ファイル(base.py)には、共通する設定を記述します。
例えば、INSTALLED_APPS や MIDDLEWARE などの基本的な設定です。
環境ごとの設定ファイルには、それぞれの環境固有の設定を記述します。
例えば、デバッグモードのオンオフやデータベースの接続情報などです。
そして、どの設定ファイルを読み込むかを manage.py や wsgi.py で設定します。
例えば、環境変数を使用して設定ファイルを指定する方法を紹介します。
# manage.py
import os
import sys
def main():
"""Run administrative tasks."""
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'config.settings.development')
try:
from django.core.management import execute_from_command_line
except ImportError as exc:
raise ImportError(
"Couldn't import Django. Are you sure it's installed and "
"available on your PYTHONPATH environment variable? Did you "
"forget to activate a virtual environment?"
) from exc
execute_from_command_line(sys.argv)
if __name__ == '__main__':
main()
django-environ を利用している前提です。
この場合、環境変数の DJANGO_SETTINGS_MODULE で切り替えられるので、環境ごとの設定をすぐに反映できますね。
ここまで見ても、ほとんどが設定関連だと思いますよね?
やはり、 config は妥当と思います(私見)。
おわりに
最終的には、プロジェクトの要件や個人/チームの好みに応じて適切な名前を選択するべきでしょう。
開発者は好みも癖も全く異なる場合が多いです。
標準的なアプローチ、もしくは誰がみても明らかな構成を採用することで、他の開発者が簡単にプロジェクト構造を理解できるようになると思います。
コメント