Cookiecutter Djangoのインストール方法、使い方、メリット・デメリット

Cookiecutter Djangoは本番環境に対応したDjangoのプロジェクトを素早く作成できるフレームワークです。

2021年9月時点ではGithubの8.5kのスター数がついており、Djangoのモジュールの中では人気が高いです。

今回はCookiecutter Djangoのインストール方法、使い方、メリット・デメリット、使ってみた感想を紹介します。

使用バージョン：3.1.13

インストール方法、実行方法

インストールには以下のコマンドを実行します。

pip install "cookiecutter>=1.7.0"

cookiecutterを実行するコマンド

cookiecutter https://github.com/pydanny/cookiecutter-django

プロジェクトの作成は対話形式で行います。

各設問の[]内はデフォルト値です。y/nの２択や、番号を選ぶタイプ、任意の文字列を入力するタイプがあります。

以下は設問の簡単な解説です。

project_name

プロジェクト名を設定します。大文字、スペースが使えます。利用箇所を調べたところ日本語でも問題なさそうですが英語が無難だと思います。

project_slug

ダッシュやスペースを使わないプロジェクトのスラッグです。

リポジトリ名や、Pythonでインポート文などで使用されます。英語推奨です。

description

プロジェクトの説明です。README.rstなどの場所で使用されます。

author_name

製作者の名前です。LICENSEなどに使われます。企業の場合は企業名にすると良いでしょう。

email

プロジェクト用のメールアドレスです。config/settings/base.pyのADMINSに使われていました。base.pyはDjangoのsettings.pyにあたるファイルです。

domain_name

プロジェクトに使用する予定のドメイン名です。設定後でも安全に変更できるので、仮のドメイン名でも良いです。

version

開始時のプロジェクトのバージョンです。

open_source_license

プロジェクトのソフトウェアライセンスです。選択肢は次のとおりです。

• MIT
• BSD
• GPLv3
• Apache Software License 2.0
• Not open source (オープンソースではありません)

timezone

プロジェクトのTIME_ZONE設定の値です。日本時間に設定したい場合は、Asia/Tokyoと入力します。

windows

プロジェクトをWindowsでの開発用に構成する必要があるかどうかを指定します。

use_pycharm

PyCharmを使って開発するかどうかを指定します。PyCharmとは統合開発環境です。

use_docker

DockerやDockerComposeを使用するかどうかを指定します。

postgresql_version

使用するPostgreSQLのバージョンを選択します。

他のDBを使用したい場合は、プロジェクト作成後に手動で変更する必要があります。

js_task_runner

JavaScriptタスクランナーを選択します。使わない場合はNoneを選択します。

cloud_provider

静的ファイルやメディアファイルのクラウドプロバイダーを選択します。使わない場合はNoneを選択します。

クラウドプロバイダーを選択しない場合、メディアファイルは機能しないことに注意してください。

mail_service

Django-Anymailが提供するメールサービスを選択します。

1. Mailgun
2. Amazon SES
3. Mailjet
4. Mandrill
5. Postmark
6. SendGrid
7. SendinBlue
8. SparkPost
9. Other SMTP

use_async

プロジェクトでUvicorn + GunicornでWebソケットを使用する必要があるかどうかを指定します。

use_drf

Django RestFrameworkを使用するかどうかを指定します。

custom_bootstrap_compilation

プロジェクトが、選択したJavaScriptタスクランナーのタスクを介したブートストラップ再コンパイルをサポートする必要があるかどうかを指定します。

これは、リアルタイムのBootstrap変数の変更に役立ちます。

use_compressor

Django Compressorを使用するかどうかを指定します。

use_celery

Celeryを使用するかどうかを指定します。

use_mailhog

MailHogを使用するかどうかを指定します。

use_sentry

Sentryを使用するかどうかを指定します。

use_whitenoise

WhiteNoiseを使用するかどうかを指定します。

use_heroku

Herokuにデプロイできるようにするかどうかを指定します。

ci_tool

テストを実行するためのCIツールを選択します。

keep_local_envs_in_vcs

.envs/.local/をVCSに保持する必要があるかどうかを指定します（ローカル環境の再現性が強く推奨されるチームで作業する場合に便利です）。

注）.env（s）は、Docker ComposeやHerokuのサポートが有効な場合にのみ使用されます。

debug

プロジェクトをデバッグ用に構成する必要があるかどうかを指定します。このオプションは、Cookiecutter Django開発者にのみ関連します。

ローカル環境で動作確認する方法

手短に動作確認をする方法を紹介します。

config/settings/local.pyの編集

デフォルトではpostgresのDBを使う設定になっているため動きません。

ローカル環境用の設定ファイルにSQLiteを使う様に以下のコードをlocal.pyに追記します。

DATABASES["default"]["ENGINE"] = 'django.db.backends.sqlite3'
DATABASES["default"]["NAME"] = ROOT_DIR / 'db.sqlite3'

venvという仮想環境を作成し、アクティベートします。作成は任意です。

※以降のコマンドはプロジェクトのルートディレクトリで実行してください。

python3 -m venv venv
. venv/bin/activate

必要なモジュールのインストール、DBの作成、スーパーユーザーの作成をします。

最後にサーバーを起動します。

pip install -r requirements/local.txt
python manage.py migrate
python manage.py createsuperuser

python manage.py runserver

サーバー起動に失敗する場合は、環境変数にDJANGO_SETTINGS_MODULEが設定されているかもしれません。

manage.pyを見ると、DJANGO_SETTINGS_MODULEのデフォルト値は、”config.settings.local”になっているためローカル環境の設定はlocal.pyに書けば良いです。

http//127.0.0.1:8000/　にアクセスすると次の様な画面になると思います。

ログインやユーザー登録はallauthの機能を使っています。

右側の黒いバーはDjango Debug Toolbarというデバッグに役立つプラグインの機能です。

Djangoの管理画面である http//127.0.0.1:8000/admin/ にもアクセスできます。

メリット・デメリット

メリット

• 認証系で便利なall-authがすぐに使える
• 設定ファイルが環境別に作成済みである
• Djangoのプロジェクト作成の参考になる
• Djangoと連携して使われるメールサーバやクラウド、CI、アプリケーションの参考になる

settings.pyやrequrementsの分割方法、CIファイルの書き方、Docker関連ファイルの書き方は非常に参考になりました。

デメリット

• 幅広い知識が必要で初心者には難しい
• Cookiecutter Djangoで作成したプロジェクトの仕組みを調べて理解する必要があり、手間がかかる。
• 使わないファイルや機能は整理する必要がある（かもしれない）
• ユニットテストにpytestが使われている

私はunittest派なのでpytestが使われている点はデメリットとしました。

幅広いプロジェクトに対応している点はメリットでもありデメリットでもあります。

使ってみた感想

幅広いタイプのプロジェクトに対応したフレームワークだと思いますが、利用用途が不明なファイルが多く調査に時間がかかりました。

localeやdocsなど今後利用するか不明なファイルもありました。

個人的にはCookiecutter Djangoはプロジェクト作成方法の参考程度に留めておき、便利な点は自分のプロジェクトに移植する使い方にしようと思いました。