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

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

Требования

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

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

setup.py

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

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

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

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

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

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

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

каталог Tmp

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

Virtualenv

Я предпочитаю virtualenvwrapper и поместить все venvs в каталог ~/.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/ в корне проекта, но еще не использовали ее.

Подключаемое приложение

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

Ответ 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
• сфинкс

Этюды

Примеры

База данных

Ответ 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/ по умолчанию.

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

Ответ 4

Вот что я следую за моей системой.

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

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

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

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

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

Ответ 5

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