web-dev-qa-db-ja.com

Djangoプロジェクトの作業ディレクトリ構造のベストプラクティス

私は実際には単一の正しい方法はないことを知っています。ただし、すべての開発者と管理者にとって適切に機能し、クリーンな状態を維持するディレクトリ構造を作成するのは難しいことがわかりました。 githubのほとんどのプロジェクトには、いくつかの標準構造があります。ただし、PC上の別のファイルとすべてのプロジェクトを整理する方法は示していません。

これらすべてのディレクトリを開発マシンで整理する最も便利な方法は何ですか？どのように名前を付け、これをサーバーに接続して展開しますか？

  • プロジェクト（あなたが取り組んでいるすべてのプロジェクト）
  • ソースファイル（アプリケーション自体）
  • リポジトリの作業コピー（gitを使用）
  • 仮想環境（これをプロジェクトの近くに配置することを好みます）
  • 静的ルート（コンパイル済み静的ファイル用）
  • メディアルート（アップロードされたメディアファイル用）
  • README
  • ライセンス
  • 文書
  • スケッチ
  • サンプル（このプロジェクトが提供するアプリケーションを使用するサンプルプロジェクト）
  • データベース（sqliteが使用される場合）
  • プロジェクトで成功するために通常必要なもの

私が解決したい問題：

  • 目的が明確になるように、ディレクトリの適切な名前。
  • すべてのプロジェクトファイル（virtualenvを含む）を1か所に保持することで、プロジェクト全体を簡単にコピー、移動、アーカイブ、削除したり、ディスク領域の使用量を見積もることができます。
  • 複製したくない別のファイルの単一のコピーを保持しながら、アプリケーション全体、リポジトリ、またはvirtualenvなどの選択したファイルセットの複数のコピーを作成します。
  • 選択した1つのディレクトリをrsyncするだけで、正しいファイルセットをサーバーに展開します。
djangodirectory-structureorganizationproject-structure
127
raacer

~/projects/ディレクトリにある2種類のDjango "プロジェクト"があり、どちらも構造が少し異なります。

  • スタンドアロンWebサイト
  • プラグ可能なアプリケーション

スタンドアロンWebサイト

ほとんどがプライベートプロジェクトですが、そうである必要はありません。通常は次のようになります。

~/projects/project_name/

docs/               # documentation
scripts/
  manage.py         # installed to PATH via setup.py
project_name/       # project dir (the one which Django-admin.py creates)
  apps/             # project-specific applications
    accounts/       # most frequent app, with custom user model
    __init__.py
    ...
  settings/         # settings for different environments, see below
    __init__.py
    production.py
    development.py
    ...

  __init__.py       # contains project version
  urls.py
  wsgi.py
static/             # site-specific static files
templates/          # site-specific templates
tests/              # site-specific tests (mostly in-browser ones)
tmp/                # excluded from git
setup.py
requirements.txt
requirements_dev.txt
pytest.ini
...

設定

主な設定は本番設定です。他のファイル（staging.py、development.pyなど）は、単にproduction.pyからすべてをインポートし、必要な変数のみをオーバーライドします。

環境ごとに、個別の設定ファイルがあります。生産、開発。また、テスト（テストランナー用）、ステージング（最終展開前のチェックとして）、およびheroku（herokuへの展開用）設定もあるプロジェクトがあります。

必要条件

むしろ、setup.pyで直接要件を指定します。 requirements_dev.txtにある開発/テスト環境に必要なもののみ。

一部のサービス（例：heroku）では、ルートディレクトリにrequirements.txtが必要です。

setup.py

setuptoolsを使用してプロジェクトを展開するときに役立ちます。 manage.pyをPATHに追加するので、manage.pyを直接（どこでも）実行できます。

プロジェクト固有のアプリ

これらのアプリをproject_name/apps/ディレクトリに配置し、相対インポートを使用してインポートしていました。

Templates/static/locale/testsファイル

これらのテンプレートと静的ファイルは、各アプリ内ではなく、グローバルなテンプレート/静的ディレクトリに配置します。これらのファイルは通常、プロジェクトのコード構造やpythonをまったく気にしない人々によって編集されます。フルスタックの開発者が単独または小規模のチームで作業している場合、アプリごとのテンプレート/静的ディレクトリを作成できます。それは本当にただの好みの問題です。

ロケールにも同じことが当てはまりますが、別のロケールディレクトリを作成すると便利な場合があります。

通常、テストは各アプリ内に配置する方が適切ですが、通常、より多くのアプリが連携して動作することをテストする統合/機能テストが多数あります。そのため、グローバルテストディレクトリは意味があります。

Tmpディレクトリ

プロジェクトルートに一時ディレクトリがあり、VCSから除外されています。開発中にメディア/静的ファイルとsqliteデータベースを保存するために使用されます。 tmp内のすべては、問題なくいつでも削除できます。

Virtualenv

virtualenvwrapperを好み、すべてのvenvを~/.venvsディレクトリに配置しますが、一緒に保持するためにtmp/内に配置することもできます。

プロジェクトテンプレート

このセットアップ用のプロジェクトテンプレートを作成しました Django-start-template

展開

このプロジェクトの展開は次のとおりです。

source $VENV/bin/activate
export Django_SETTINGS_MODULE=project_name.settings.production
git pull
pip install -r requirements.txt

# Update database, static files, locales
manage.py syncdb  --noinput
manage.py migrate
manage.py collectstatic --noinput
manage.py makemessages -a
manage.py compilemessages

# restart wsgi
touch project_name/wsgi.py

rsyncの代わりにgitを使用できますが、環境を更新するにはコマンドのバッチを実行する必要があります。

最近、私は[Django-deploy][2]アプリを作成しました。これにより、単一の管理コマンドを実行して環境を更新することができますが、1つのプロジェクトにのみ使用しており、まだ実験中です。

スケッチと下書き

グローバルなtemplates/ディレクトリ内に配置するテンプレートのドラフト。プロジェクトのルートにsketches/フォルダーを作成できると思いますが、まだ使用していません。

プラグ可能なアプリケーション

これらのアプリは通常、オープンソースとして公開する準備ができています。 Django-forme から以下の例を取り上げました

~/projects/Django-app/

docs/
app/
tests/
example_project/
LICENCE
MANIFEST.in
README.md
setup.py
pytest.ini
tox.ini
.travis.yml
...

ディレクトリの名前は明確です（願っています）。私はテストファイルをアプリディレクトリの外に置きましたが、それは実際には重要ではありません。 READMEとsetup.pyを提供することが重要です。そのため、パッケージはpipを使用して簡単にインストールできます。

200
Tomáš Ehrlich

私の答えは、私自身の実務経験にインスパイアされており、そのほとんどが Djangoの2つのスクープ であり、これを強くお勧めします。いくつかのポイントに答えるだけで、改善や修正は歓迎します。しかし、同じ目的を達成するために、より適切な方法もあります。

プロジェクト
個人ディレクトリにメインフォルダーがあり、そこで作業しているすべてのプロジェクトを管理しています。

ソースファイル
個人的にDjangoプロジェクトルートをプロジェクトのリポジトリルートとして使用しています。しかし、本では両方を分離することをお勧めします。これはより良いアプローチだと思うので、私のプロジェクトで徐々に変更を加えていきたいです。

project_repository_folder/
    .gitignore
    Makefile
    LICENSE.rst
    docs/
    README.rst
    requirements.txt
    project_folder/
        manage.py
        media/
        app-1/
        app-2/
        ...
        app-n/
        static/
        templates/
        project/
            __init__.py
            settings/
                __init__.py
                base.py
                dev.py
                local.py
                test.py
                production.py
            ulrs.py
            wsgi.py

リポジトリ
GitまたはMercurialは、Django開発者の間で最も人気のあるバージョン管理システムのようです。バックアップ用の最も一般的なホスティングサービス GitHub および Bitbucket 。

仮想環境
virtualenvとvirtualenvwrapperを使用しています。 2番目のものをインストールしたら、作業ディレクトリを設定する必要があります。私の/ home/envsディレクトリにあります。virtualenvwrapperインストールガイドで推奨されています。しかし、最も重要なことはそれがどこにあるかではないと思います。仮想環境で作業する際の最も重要なことは、requirements.txtファイルを最新の状態に保つことです。

pip freeze -l > requirements.txt

静的ルート
プロジェクトフォルダー

メディアルート
プロジェクトフォルダー

README
リポジトリルート

ライセンス
リポジトリルート

ドキュメント
リポジトリのルート。このpythonパッケージは、ドキュメントの管理を容易にするのに役立ちます。

スケッチ

例

データベース

14
cor

新しいsettings/ディレクトリを作成したくない。 settings_dev.pyとsettings_production.pyという名前のファイルを追加するだけなので、BASE_DIRを編集する必要はありません。以下のアプローチは、デフォルト構造を変更する代わりに増やします。

mysite/                   # Project
    conf/
        locale/
            en_US/
            fr_FR/
            it_IT/
    mysite/
        __init__.py
        settings.py
        settings_dev.py
        settings_production.py
        urls.py
        wsgi.py
    static/
        admin/
            css/           # Custom back end styles
        css/               # Project front end styles
        fonts/
        images/
        js/
        sass/
    staticfiles/
    templates/             # Project templates
        includes/
            footer.html
            header.html
        index.html
    myapp/                 # Application
        core/
        migrations/
            __init__.py
        templates/         # Application templates
            myapp/
                index.html
        static/
            myapp/
                js/  
                css/
                images/
        __init__.py
        admin.py
        apps.py
        forms.py
        models.py
        models_foo.py
        models_bar.py
        views.py
    templatetags/          # Application with custom context processors and template tags
        __init__.py
        context_processors.py
        templatetags/
            __init__.py
            templatetag_extras.py
    gulpfile.js
    manage.py
    requirements.txt

私はこれを考える：

    settings.py
    settings_dev.py
    settings_production.py

これよりも優れています：

    settings/__init__.py
    settings/base.py
    settings/dev.py
    settings/production.py

この概念は他のファイルにも適用されます。

通常、node_modules/とbower_components/は、デフォルトのstatic/フォルダー内のプロジェクトディレクトリに配置します。

Gitサブモジュール用のvendor/ディレクトリもありますが、通常はstatic/フォルダーに配置します。

6
isar

私のシステムで私が従うことはここにあります。

  1. すべてのプロジェクト：私のホームフォルダにprojectsディレクトリがあります、つまり~/projects 。すべてのプロジェクトはその中にあります。

  2. 個々のプロジェクト：私は、標準化された構造テンプレートに従っています。 Django-skel 個々のプロジェクト用。基本的には、すべての静的ファイルとメディアファイル、およびすべてを処理します。

  3. 仮想環境：私はすべてを保存するために私の家の中にvirtualenvsフォルダを持っていますシステムの仮想環境、つまり~/virtualenvsこれにより、柔軟性が得られ、私が持っているすべての仮想環境がわかり、簡単に使用できます

上記の3つは、私の作業環境の主要なパーティションです。

あなたが言及した他のすべての部分は、ほとんどプロジェクトごとに依存しています（つまり、プロジェクトごとに異なるデータベースを使用する可能性があります）。したがって、それらは個々のプロジェクトに常駐する必要があります。

2
Sahil kalra

Djangoドキュメンテーションによると、従うことができる適切なディレクトリ構造は次のとおりです。

[projectname]/                  <- project root
├── [projectname]/              <- Django root
│   ├── __init__.py
│   ├── settings/
│   │   ├── common.py
│   │   ├── development.py
│   │   ├── i18n.py
│   │   ├── __init__.py
│   │   └── production.py
│   ├── urls.py
│   └── wsgi.py
├── apps/
│   └── __init__.py
├── configs/
│   ├── Apache2_vhost.sample
│   └── README
├── doc/
│   ├── Makefile
│   └── source/
│       └── *snap*
├── manage.py
├── README.rst
├── run/
│   ├── media/
│   │   └── README
│   ├── README
│   └── static/
│       └── README
├── static/
│   └── README
└── templates/
    ├── base.html
    ├── core
    │   └── login.html
    └── README

最新のディレクトリ構造については、 https://Django-project-skeleton.readthedocs.io/en/latest/structure.html を参照してください。

1
Sachin Vardhan