Примеры использования новой структуры проекта Django 1.4?

Я предполагаю, что это своего рода дополнительный вопрос к Где должен я создаю приложения django в 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. Существуют ли варианты использования, когда наличие приложений внутри/вне проекта оказывает нетривиальное влияние?

django project-structure
person Adam    schedule 21.08.2012    source источник

Ответы (2)


arrow_upward
6
arrow_downward

  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
person frog32    schedule 21.08.2012

arrow_upward
2
arrow_downward

Я пометил более ранний ответ как ответ, но наткнулся на этот пост в блоге из архивов IRC, в котором, похоже, есть дополнительная информация.

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

Как я понимаю, суть в следующем:

  • При разработке manage.py неявно настраивает PYTHONPATH для просмотра кода уровня проекта, в результате чего import myapp работает для приложения, определенного внутри проекта.
  • Когда вы развертываете, вы обычно не запускаете manage.py, поэтому вам нужно будет сказать import myproject.myapp, поэтому при развертывании все ломается, если вы об этом не знаете.
  • «Стандартное» решение состоит в том, чтобы добавить проект в PYTHONPATH, но это приводит к двойному импорту (myapp и myproject.myapp), что может привести к странному поведению таких вещей, как сигналы.

Таким образом, структура проекта 1.4, по-видимому, в основном предназначена для того, чтобы исключить возможность того, что разработчики будут полагаться на странный эффект manage.py.

person Adam    schedule 22.08.2012