Структура и управление проектом Django 1.4

категория: Django
Давно следовало разобрать эту тему по полочкам, я еще в самом начале изучения Django очень путался - где что находится и должно находиться, в особенности с версиями ниже Django 1.4. Натолкнулся на очень полезную ссылку, в которой описаны лучшие практики организации структуры Django проектов с максимальной ясностью и доступностью. Без длительных предисловий начнем с создания проекта. Основы Создаем проект my_django:
$ django-admin.py startproject my_django
$ cd my_django
$ tree .
.
├─ my_django
│   ├─ __init__.py
│   ├─ settings.py
│   ├─ urls.py
│   └─ wsgi.py
└─ manage.py
В корневой папке my_django мы получили: - папку с проектом my_django - скрипт manage.py для управления проектом Внутри каталога my_django проекта мы получили: - settings.py – файл с настройками проекта - urls.py – файл с корневыми ссылками - swgi.py – содержит конфигурации WSGI приложения для взаимодействия с сервером - __init__.py – файл, который ставит в известность Python, что эта директория является модулем Python Это был стандартный скелет проекта Django 1.4, давайте начнем делать усовершенствования. Управление зависимостями проекта Первое усовершенствование которое мы сделаем — добавим файл requirements.txt в наш проект. Каждый Django проект должен иметь requirements.txt со списком всех используемых python пакетов в проекте без которых сайт не будет работать на продакшн сервере.. Можно сделать так:
$ pip freeze > requirements.txt
Не используемые пакеты нужно удалить, к примеру, содержание может выглядеть следующим образом:
Django==1.4
psycopg2==2.4.5
South==0.7.3
gunicorn==0.14.1
newrelic==1.2.0.246
django-celery==2.4.2
Сама идея requirements.txt лежит в том, чтобы любой разработчик вашей команды или пользователь Git мог знать какие пакеты ему требуются для запуска вашего проекта и не искал нужные версии. Просто устанавливаем все что нужно:
$ pip install -r requirements.txt
Разделение зависимостей Окружение разработки требует других зависимостей чем окружение продакшена. Конечно можно засунуть все необходимые пакеты одним списком в requirements.txt, но зачем другим пользователям качать не нужные пакеты для запуска приложения. Лучше сделать несколько файлов и разделить их. К примеру сделаем так:
$ ls
my_django  manage.py
$ mkdir requirements
$ touch requirements/{common.txt,dev.txt,prod.txt,test.txt}
$ tree .
.
├─ my_django
│   ├─ __init__.py
│   ├─ settings.py
│   ├─ urls.py
│   └─ wsgi.py
├─ manage.py
├─ requirements
│   ├─ common.txt
│   ├─ dev.txt
│   ├─ prod.txt
│   └─ test.txt
└─ requirements.txt
Мы создали четыре файла с зависимостями: common.txt — общие пакеты для всех окружений, dev.txt — для разработки, test.txt — для тестирования, prod.txt — для продакшн сервера, если нужно еще для чего-то — то создавайте еще файл. Если ваше приложение имеет только окружение для разработки — то создайте только dev.txt. В common.txt записываем все необходимые приложения, без которых не сможет работать ваш проект, пример:
Django==1.4
django-cache-machine==0.6
django-celery==2.5.5
django-dajaxice==0.2
django-guardian==1.0.4
django-kombu==0.9.4
django-pagination==1.0.7
django-sorting==0.1
django-tastypie==0.9.11
Fabric==1.4.1
lxml==2.3.4
pyst2==0.4
South==0.7.4
Sphinx==1.1.3
Пример dev.txt:
-r common.txt
django-debug-toolbar==0.9.4
При выполнении:
$ pip install -r requirements/dev.txt
- установятся джанго дебаг-инструменты и все пакеты из common.txt. Остальные зависимости ставятся по аналогии. Разделение приложений и библиотек: Следующим шагом управления любым хорошим проектом Django — это разделение приложений и библиотек. Всем известно, что любой Django проект состоит из разных приложений. Некоторые из них состоят из моделей, представлений и т. д., другие являются просто хелперами, обеспечивающими определенным функционалом, который используется в других приложениях. Очень часто хелперы — это собственные шаблонные теги, управляющие команды и другие куски кода, которые не принадлежат ни одному из приложений, и не понятно, где они должны находиться. К счастью есть простой способ структурирования Django проекта, чтобы: - разработчики могли легко найти ваши приложения; - разработчики могли легко найти ваши библиотеки (хелперы); - основная директория проекта не была забита всяким приложениями, хелперами, управляющими командами скинутыми в кучу. В каждом проекте лучше всего создать две директории apps и libs, в которых будут находиться приложения и библиотеки. В корневой директории проекта сделаем:
$ mkdir my_django/apps
$ mkdir my_django/libs
$ touch my_django/apps/__init__.py
$ touch my_django/libs/__init__.py
$ tree .
.
├─ my_django
│   ├─ apps
│   │   └─ __init__.py
│   ├─ __init__.py
│   ├─ libs
│   │   └─ __init__.py
│   ├─ settings.py
│   ├─ urls.py
│   └─ wsgi.py
├─ manage.py
├─ requirements
│   ├─ common.txt
│   ├─ dev.txt
│   ├─ prod.txt
│   └─ test.txt
└─ requirements.txt
Теперь создадим приложения и хелперы, и раскидаем их по своим местам:
$ cd my_django/apps
$ django-admin.py startapp my_blog
$ django-admin.py startapp my_news
$ cd ../libs
$ django-admin.py startapp my_management
$ django-admin.py startapp my_display
$ cd ../..
$ tree .
.
├─ my_django
│   ├─ apps
│   │   ├─ my_blog
│   │   │   ├─ __init__.py
│   │   │   ├─ models.py
│   │   │   ├─ tests.py
│   │   │   └─ views.py
│   │   ├─ __init__.py
│   │   └─ my_news
│   │         ├─ __init__.py
│   │         ├─ models.py
│   │         ├─ tests.py
│   │         └─ views.py
│   ├─ __init__.py
│   ├─ libs
│   │   ├─ my_display
│   │   │   ├─ __init__.py
│   │   │   ├─ models.py
│   │   │   ├─ tests.py
│   │   │   └─ views.py
│   │   ├─ __init__.py
│   │   └─ my_management
│   │       ├─ __init__.py
│   │       ├─ models.py
│   │       ├─ tests.py
│   │       └─ views.py
│   ├─ settings.py
│   ├─ urls.py
│   └─ wsgi.py
├─ manage.py
├─ requirements
│   ├─ common.txt
│   ├─ dev.txt
│   ├─ prod.txt
│   └─ test.txt
└─ requirements.txt
Теперь наш проект начинает приобретать настоящую структуру. Осталось только правильно прописать импорты во вьюшках, пример my_blog/views.py:
from my_django.apps.news.models import News
from my_django.libs.display.templatetags import sidebar
Последним штрихом будет прописывание путей в settings.py:
INSTALLED_APPS = (
    ...
    'my_django.apps.my_blog',
    'my_django.apps.my_news',
    ...
)
Делаем модуль настроек Будем разделать настройки Django для окружений разработки, тестирования и продакшена, как это делали с requirements.txt
$ rm my_django/settings.py
$ mkdir my_django/settings
$ touch my_django/settings/{__init__.py,common.py,dev.py,prod.py,test.py}
$ tree .
.
├─ my_django
│   ├─ apps
│   │   ├─ my_blog
│   │   │   ├─ __init__.py
│   │   │   ├─ models.py
│   │   │   ├─ tests.py
│   │   │   └─ views.py
│   │   ├─ __init__.py
│   │   └─ my_news
│   │       ├─ __init__.py
│   │       ├─ models.py
│   │       ├─ tests.py
│   │       └─ views.py
│   ├─ __init__.py
│   ├─ libs
│   │   ├─ my_display
│   │   │   ├─ __init__.py
│   │   │   ├─ models.py
│   │   │   ├─ tests.py
│   │   │   └─ views.py
│   │   ├─ __init__.py
│   │   └─ my_management
│   │         ├─ __init__.py
│   │         ├─ models.py
│   │         ├─ tests.py
│   │         └─ views.py
│   ├─ settings
│   │   ├─ common.py
│   │   ├─ dev.py
│   │   ├─ __init__.py
│   │   ├─ prod.py
│   │   └─ test.py
│   ├─ urls.py
│   └─ wsgi.py
├─ manage.py
├─ requirements
│   ├─ common.txt
│   ├─ dev.txt
│   ├─ prod.txt
│   └─ test.txt
└─ requirements.txt
В итоге получился хорошо структурированный Django проект для любых задумок и реализаций. Всего наилучшего.


blog comments powered by Disqus