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

Який найзручніший спосіб організувати всі ці каталоги на машині розвитку? Як ви їх називаєте та як це підключити та розгорнути на сервері?

• проекти (усі проекти, над якими ви працюєте)
• вихідні файли (сама програма)
• робоча копія сховища (я використовую git)
• віртуальне середовище (я вважаю за краще розмістити це біля проекту)
• статичний корінь (для складених статичних файлів)
• медіа-корінь (для завантажених медіа-файлів)
• ЧИТАЙТЕ
• ЛІЦЕНЗІЯ
• документи
• ескізи
• Приклади (приклад проекту, який використовує додаток, наданий цим проектом)
• база даних (у разі використання sqlite)
• все, що вам зазвичай потрібно для успішної роботи над проектом

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

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

У моєму ~/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 можна було будь-коли видалити без проблем.

Віртуалєв

Я віддаю перевагу 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/в корені проекту, але ще не використовували її.

Підключений додаток

Зазвичай ці програми готуються до публікації у відкритому коді. Нижче я взяв приклад із 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 

Папка « Static Root Project»

Папка Project 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, але зазвичай я розміщую їх у static/папці.

Ось що я дотримуюся в моїй системі.

1. Усі проекти : У моїй домашній папці є каталог проектів, тобто ~/projects. Усі проекти опираються всередині нього.

2. Індивідуальний проект : Я дотримуюсь стандартизованого шаблону структури, що використовується багатьма розробниками під назвою django-skel для окремих проектів. В основному він піклується про всі ваші статичні файли та мультимедійні файли та все.

3. Віртуальне середовище : у мене в папці virtualenvs всередині мого дому, щоб зберігати всі віртуальні середовища в системі, тобто ~/virtualenvs. Це дає мені гнучкість, що я знаю, які всі віртуальні середовища у мене є, і я можу легко використовувати

Наведені вище 3 - це основні розділи мого робочого середовища.

Усі інші частини, про які ви згадали, в основному залежать від проекту до основи проекту (тобто ви можете використовувати різні бази даних для різних проектів). Тож вони повинні проживати в своїх окремих проектах.

Відповідно до скелету проекту 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 для останньої структури каталогів.

Ви можете використовувати 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