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


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

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

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

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

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

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

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

требования

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

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

setup.py

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

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

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

Templates / static / locale / tests files

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

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

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

каталог Tmp

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

Virtualenv

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

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

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

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

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

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

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

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

Pluggable применение

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

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

pip freeze -l > requirements.txt 

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

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

README
Корень репозитория

лицензия
Корень репозитория

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

эскизы

примеры

база данных

я не люблю создавать новые . Я просто добавляю файлы с именем 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. Индивидуальному Проекту: Я следую за a стандартизированный шаблон структуры используется многими разработчиками под названием django-skel для индивидуальных проектов. В основном он берет на себя все ваши статические файлы и средств массовой информации файлы и все.

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

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

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