1

これは、django 1.4 で django アプリを作成する必要がある場所に対するフォローアップの質問のようなものだと思います。 最終的な答えは、「Django がプロジェクト構造を変更した理由を誰も知らない」というものでした。これは少し物足りないようです。

新しい Django プロジェクトを開始しています。現在、http : //www.deploydjango.com/django_project_structure/index.html で概説されている基本構造に従っています。

├── project
│   ├── apps
│   │   ├── app1
│   │   └── app2
│   ├── libs
│   │   ├── lib1
│   │   └── lib2
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── manage.py

しかし、共通のプロジェクト レベル コンポーネントを備えた大部分が独立したアプリケーションで構成されるマルチ開発者環境も想定していると思います。そのため、プロジェクト パスとアプリ パスを分離した方がすっきりしているように思えます。

├── project
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── apps
│   ├── app1
│   └── app2
├── libs
│   ├── lib1
│   └── lib2
└── manage.py

ただし、これについて特定の非様式的な論理的根拠を考え出すのは困難です. (私はこれまで主に単一アプリのプロジェクトしか扱っていなかったので、ここで何かが欠けている可能性があります。)

主に、私は Django 1.4 が後者の方向に進んでいるように見えるという事実に動機付けられています。この変更の動機となった理論的根拠または予想されるユースケースがあると思いますが、それが何であるかについては憶測しか見ていません。

質問:

  1. 1.4 プロジェクト構造の変更の動機は何ですか?
  2. プロジェクトの内外にアプリを配置することで重大な影響が生じるユースケースはありますか?
4

2 に答える 2

6

  1. 次のようなインポートがなくなるため、プロジェクトからアプリを抽出するのがはるかに簡単になります。

    from projectname.appname.models import MyModel

    代わりに、Python パッケージ経由でインストールされたアプリをインポートするのと同じ方法でそれらをインポートします。

  2. i18n を使用している場合、makemessages は現在のディレクトリで翻訳文字列を検索するため、これは影響を与える可能性があります。単一の .po ファイルを使用してアプリとプロジェクトを翻訳する良い方法は、プロジェクト ディレクトリの外にロケール フォルダーを作成することです。

    ├── project
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── app1
├── app2
├── locale
│   ├── en
│   └── de
└── manage.py
于 2012-08-21T18:36:33.783 に答える
2

以前の回答を回答としてマークしましたが、追加情報があると思われる IRC アーカイブからこのブログ投稿に出くわしました。

http://blog.tinbrain.net/blog/2012/mar/15/django-vs-pythonpath/

私が理解しているように、要点は次のとおりです。

  • 開発中は、プロジェクト レベルのコードを表示するようにmanage.py 暗黙的に設定され、プロジェクト内で定義されたアプリで機能する結果が得られます。PYTHONPATHimport myapp
  • 展開するとき、通常は を実行しないmanage.pyので、 と言わimport myproject.myappなければなりません。したがって、これを知らないと、展開時に問題が発生します。
  • 「標準的な」修正は、プロジェクトを に追加することですPYTHONPATHが、これにより二重インポート (myappおよびmyproject.myapp) が発生し、シグナルなどで奇妙な動作が発生する可能性があります。

したがって、1.4 プロジェクトの構造は、開発者がmanage.py.

于 2012-08-22T17:48:58.250 に答える