新的Django 1.4项目结构的用例?

时间:2012-08-21 18:16:48

标签: django project-structure

我想这对Where should i create django apps in django 1.4?来说是一个后续问题。最后的答案似乎是“没人知道为什么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. 是否存在项目内/外的应用程序产生非平凡影响的用例?

2 个答案:

答案 0 :(得分: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
    

答案 1 :(得分:2)

我将早期的回复标记为答案,但我在IRC档案中遇到了这篇博文,似乎有一些额外的信息。

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

据我了解,要点是:

  • 在开发时,manage.py 隐式设置PYTHONPATH以查看项目级代码,结果import myapp适用于某个应用在项目内部定义。
  • 部署时,通常不会运行manage.py,因此您必须说import myproject.myapp,因此如果您不了解此情况,则部署会中断。
  • “标准”修复是将项目添加到PYTHONPATH,但这导致双重导入(myappmyproject.myapp),这会对信号之类的事情产生奇怪的行为

所以1.4项目结构似乎主要是为了消除开发人员依赖manage.py的奇怪效应的可能性。