Лучшая практика для рабочей структуры каталогов проекта Django

Я знаю, что на самом деле нет ни одного правильного пути. Однако я обнаружил, что трудно создать структуру каталогов, которая хорошо работает и остается чистой для каждого разработчика и администратора. В большинстве проектов на github существует стандартная структура. Но он не показывает способ организации других файлов и всех проектов на ПК.

каков наиболее удобный способ организации всех этих каталогов на машине разработки? Как вы их называете, и как вы подключаетесь и развертываете это на сервер?

  • проекты (все проекты, над которыми вы работаете)
  • исходные файлы (само приложение)
  • рабочая копия репозитория (я использую git)
  • виртуальная среда (я предпочитаю размещать это рядом с проектом)
  • static root (для скомпилированных статических файлов)
  • Media root (для загруженных носителей файлы)
  • README
  • лицензия
  • документы
  • эскизы
  • примеры (Пример проекта, который использует приложение, предоставленное этим проектом)
  • база данных (в случае использования sqlite)
  • все остальное, что необходимо для успешной работы над проектом

проблемы, которые я хочу решить:

  • хорошие имена каталогов, так что их целью является четкий.
  • сохранение всех файлов проекта (включая virtualenv) в одном месте, поэтому я могу легко копировать, перемещать, архивировать, удалять весь проект или оценивать использование дискового пространства.
  • создание нескольких копий некоторых выбранных наборов файлов, таких как все приложение, репозиторий или virtualenv, сохраняя при этом одну копию других файлов, которые я не хочу клонировать.
  • развертывание правильного набора файлов на сервере просто путем rsyncing выбранного одного dir.

4 ответов


есть два вида "проектов" Django, которые у меня есть в моем , оба имеют немного другую структуру.:

  • автономные сайты
  • замены приложения

автономный сайт

в основном частные проекты, но не обязательно. Обычно это выглядит так:

~/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 и переопределить только нужные переменные.

для каждой среды существуют отдельные файлы настроек, например. производство, развитие. I некоторые проекты у меня также есть тестирование( для test runner), постановка (как проверка перед окончательным развертыванием) и Heroku (для развертывания в heroku) настройки.

требования

я скорее указываю требования в setup.py напрямую. Только те, которые необходимы для среда разработки / тестирования, в которой я работаю requirements_dev.txt.

некоторые услуги (например. heroku) требует иметь requirements.txt в корневом каталоге.

setup.py

полезно при развертывании проекта с помощью setuptools. Он добавляет manage.py to PATH, так что я могу запустить manage.py напрямую (в любом месте).

приложения для конкретных проектов

я использовал, чтобы поместить эти приложения в project_name/apps/ каталог и импортировать их использование относительного импорта.

Шаблоны / статические/языковые / тестовые файлы

I поместите эти шаблоны и статические файлы в глобальный каталог templates/static, а не внутри каждого приложения. Эти файлы обычно редактируются людьми, которым наплевать на код проекта структура или python вообще. Если вы разработчик полного стека, работающий в одиночку или в небольшой команде вы можете создавать шаблоны для каждого приложения / статический каталог. Это просто вопрос вкуса.

то же самое относится к языковому стандарту, хотя иногда удобно создавать отдельный язык справочник.

тесты обычно лучше размещать внутри каждого приложения, но обычно их много интеграция / функциональные тесты, которые тестируют больше приложений, работающих вместе, поэтому глобальный каталог тестов имеет смысл.

каталог Tmp

в корне проекта есть временный каталог, исключенный из VCS. Он привык храните медиа / статические файлы и базу данных sqlite во время разработки. Все в tmp можно удалить в любое время без каких-либо проблемы.

Virtualenv

предпочитаю virtualenvwrapper и поставить все venvs в , но вы можете поместить его внутри tmp/ чтобы держать его вместе.

шаблон проекта

я создал шаблон проекта для этой установки, django-старт-шаблон

развертывание

развертывание этого проекта следующее:

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] app, который позволяет мне запускать одну команду управления для обновления среды, но я использовал его только для одного проекта, и я все еще экспериментирую с ним.

эскизы и проекты

проект шаблонов я размещаю внутри global . Я думаю можно создать папку sketches/ в корне проекта, но еще не использовал его.

Pluggable применение

эти приложения обычно готовятся к публикации с открытым исходным кодом. Я привел пример. ниже Джанго-форме

~/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.


мой ответ вдохновлен моим собственным опытом работы, и в основном в книге две ложки Джанго который я настоятельно рекомендую, и где вы можете найти более подробное объяснение всего. Я просто отвечу на некоторые вопросы, и любое улучшение или коррекция будет приветствоваться. Но также могут быть более правильные манеры для достижения той же цели.

проекты
У меня есть основная папка в моем личном каталоге, где я поддерживаю все проекты, над которыми я работаю.

Исходные Файлы
Я лично использую корень проекта 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. После установки второго необходимо настроить рабочий каталог. Мой на моем /главная/envs каталог, как рекомендуется в руководстве по установке virtualenvwrapper. Но я не думаю, что самое главное, где он находится. Самое главное при работе с виртуальные среды сохраняют требования.txt файл в актуальном состоянии.

pip freeze -l > requirements.txt 

Статический Корень
Папка проекта

Media Root
Папка проекта

README
Репозиторий root

лицензия
Репозиторий root

документы
Корень хранилища. Это python пакеты могут помочь вам сделать проще mantaining ваш документация:

эскизы

примеры

база данных


мне не нравится создавать новый . Я просто добавляю файлы с именем 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/ в каталоге проекта по умолчанию .

времени vendor/ каталог для подмодулей Git, но обычно я помещаю их в .


вот что я следую в своей системе.

  1. Все Проекты: есть каталог проектов в моей домашней папке то есть ~/projects. Все проекты покоятся внутри него.

  2. Индивидуальному Проекту: Я следую шаблон стандартизированной структуры используется многими разработчиками под названием Джанго-скел для индивидуальных проектов. Он в основном заботится обо всех ваших статических файлах и носителях файлы и все.

  3. виртуальная среда: у меня папка virtualenvs внутри моего дома для хранения всех виртуальных сред в системе, т. е. ~/virtualenvs . Это дает мне гибкость что я знаю, какие все виртуальные среды у меня есть и могу легко использовать!--3-->

вышеуказанные 3 являются основными разделами моей рабочей среды.

все остальные части вы упомянули в основном зависят от проекта к проекту (т. е. можно использовать разные базы данных для разных проектов). Поэтому они должны жить в своих индивидуальных проектах.