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

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

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

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

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

В моем ~/projects/каталоге есть два вида «проектов» 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и переопределить только необходимые переменные.

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

Требования

Я скорее уточняю требования в 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/чтобы сохранить вместе.

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

Я создал шаблон проекта для этой установки, 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/в корне проекта, но еще не использовал ее.

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

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

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

pip freeze -l > requirements.txt 

Папка статического корневого проекта

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

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

ЛИЦЕНЗИЯ
Корень хранилища

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

• ReStructuredText
• сфинкс

Этюды

Примеры

База данных

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

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

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

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

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

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

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

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

[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 для получения последней структуры каталогов.

Вы можете использовать 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