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

Question

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

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

• проекты (все проекты, над которыми вы работаете)
• исходные файлы (само приложение)
• рабочая копия репозитория (я использую git)
• виртуальная среда (я предпочитаю размещать это рядом с проектом)
• статический корень (для скомпилированных статических файлов)
• медиа-корень (для загруженных медиа-файлов)
• ПРОЧТИ МЕНЯ
• ЛИЦЕНЗИЯ
• документы
• эскизы
• примеры (пример проекта, который использует приложение, предоставленное этим проектом)
• база данных (в случае использования sqlite)
• все остальное, что вам обычно нужно для успешной работы над проектом

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

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

Answer 1

Есть два вида "проектов" Django, которые у меня есть в моем ~/projects/ каталог, оба имеют немного разную структуру.

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

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

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

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

Для каждой среды существуют отдельные файлы настроек, например. производство, разработка. У меня есть несколько проектов для тестирования (для тестового бегуна), постановки (в качестве проверки перед финальным развертыванием) и настройки героку (для развертывания на героку).

Требования

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

Для некоторых услуг (например, heroku) требуется наличие requirements.txt в корневой директории.

setup.py

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

Проектные приложения

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

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

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

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

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

Каталог Tmp

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

Virtualenv

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

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

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

Эскизы и чертежи

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

Сменное приложение

Эти приложения обычно готовы к публикации с открытым исходным кодом. Я взял пример ниже с 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,

Answer 2

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

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

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

pip freeze -l > requirements.txt 

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

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

ПРОЧТИ МЕНЯ
Корень репозитория

ЛИЦЕНЗИЯ
Корень репозитория

документы
Корень репозитория. Эти пакеты Python могут помочь вам упростить управление вашей документацией:

• ReStructuredText
• сфинкс

Этюды

Примеры

База данных

Answer 3

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

Когда-нибудь vendor/ каталог для Git Submodules, но обычно я помещаю их в static/ папка.

Answer 4

Согласно скелету проекта Django, правильная структура каталогов, которой можно придерживаться, следующая:

[projectname]/                  <- project root
├── [projectname]/              <- Django root
│   ├── __init__.py
│   ├── settings/
│   │   ├── common.py
│   │   ├── development.py
│   │   ├── i18n.py
│   │   ├── __init__.py
│   │   └── production.py
│   ├── urls.py
│   └── wsgi.py
├── apps/
│   └── __init__.py
├── configs/
│   ├── apache2_vhost.sample
│   └── README
├── doc/
│   ├── Makefile
│   └── source/
│       └── *snap*
├── manage.py
├── README.rst
├── run/
│   ├── media/
│   │   └── README
│   ├── README
│   └── static/
│       └── README
├── static/
│   └── README
└── templates/
    ├── base.html
    ├── core
    │   └── login.html
    └── README

См. https://django-project-skeleton.readthedocs.io/en/latest/structure.html для получения последней структуры каталогов.

Answer 5

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

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

2. Индивидуальный проект: я следую стандартному шаблону структуры, используемому многими разработчиками под названием django-skel для отдельных проектов. Это в основном заботится обо всех ваших статических файлах и медиа-файлах и все.

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

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

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

Answer 6

Вы можете использовать репозиторий https://github.com/Mischback/django-project-skeleton.

Выполните команду ниже:

$ django-admin startproject --template=https://github.com/Mischback/django-project-skeleton/archive/development.zip [projectname]

Структура примерно такая:

[projectname]/                  <- project root
├── [projectname]/              <- Django root
│   ├── __init__.py
│   ├── settings/
│   │   ├── common.py
│   │   ├── development.py
│   │   ├── i18n.py
│   │   ├── __init__.py
│   │   └── production.py
│   ├── urls.py
│   └── wsgi.py
├── apps/
│   └── __init__.py
├── configs/
│   ├── apache2_vhost.sample
│   └── README
├── doc/
│   ├── Makefile
│   └── source/
│       └── *snap*
├── manage.py
├── README.rst
├── run/
│   ├── media/
│   │   └── README
│   ├── README
│   └── static/
│       └── README
├── static/
│   └── README
└── templates/
    ├── base.html
    ├── core
    │   └── login.html
    └── README