Лучшая практика для рабочей структуры каталогов проекта Django
Я знаю, что на самом деле нет ни одного правильного пути. Однако я обнаружил, что трудно создать структуру каталогов, которая хорошо работает и остается чистой для каждого разработчика и администратора. В большинстве проектов на github существует стандартная структура. Но он не показывает способ организации других файлов и всех проектов на ПК.
каков наиболее удобный способ организации всех этих каталогов на машине разработки? Как вы их называете, и как вы подключаетесь и развертываете это на сервер?
- проекты (все проекты, над которыми вы работаете)
- исходные файлы (само приложение)
- рабочая копия репозитория (я использую git)
- виртуальная среда (я предпочитаю размещать это рядом с проектом)
- static root (для скомпилированных статических файлов)
- Media root (для загруженных носителей файлы)
- README
- лицензия
- документы
- эскизы
- примеры (Пример проекта, который использует приложение, предоставленное этим проектом)
- база данных (в случае использования sqlite)
- все остальное, что необходимо для успешной работы над проектом
проблемы, которые я хочу решить:
- хорошие имена каталогов, так что их целью является четкий.
- сохранение всех файлов проекта (включая virtualenv) в одном месте, поэтому я могу легко копировать, перемещать, архивировать, удалять весь проект или оценивать использование дискового пространства.
- создание нескольких копий некоторых выбранных наборов файлов, таких как все приложение, репозиторий или virtualenv, сохраняя при этом одну копию других файлов, которые я не хочу клонировать.
- развертывание правильного набора файлов на сервере просто путем rsyncing выбранного одного dir.
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
и переопределить только нужные переменные.
для каждой среды существуют отдельные файлы настроек, например. производство, развитие. I некоторые проекты у меня также есть тестирование( для test runner), постановка (как проверка перед окончательным развертыванием) и Heroku (для развертывания в heroku) настройки.
требования
я скорее указываю требования в setup.py напрямую. Только те, которые необходимы для
среда разработки / тестирования, в которой я работаю requirements_dev.txt
.
некоторые услуги (например. heroku) требует иметь requirements.txt
в корневом каталоге.
setup.py
полезно при развертывании проекта с помощью setuptools
. Он добавляет manage.py
to PATH
, так что я могу запустить manage.py
напрямую (в любом месте).
приложения для конкретных проектов
я использовал, чтобы поместить эти приложения в project_name/apps/
каталог и импортировать их
использование относительного импорта.
Шаблоны / статические/языковые / тестовые файлы
I поместите эти шаблоны и статические файлы в глобальный каталог templates/static, а не внутри каждого приложения. Эти файлы обычно редактируются людьми, которым наплевать на код проекта структура или python вообще. Если вы разработчик полного стека, работающий в одиночку или в небольшой команде вы можете создавать шаблоны для каждого приложения / статический каталог. Это просто вопрос вкуса.
то же самое относится к языковому стандарту, хотя иногда удобно создавать отдельный язык справочник.
тесты обычно лучше размещать внутри каждого приложения, но обычно их много интеграция / функциональные тесты, которые тестируют больше приложений, работающих вместе, поэтому глобальный каталог тестов имеет смысл.
каталог Tmp
в корне проекта есть временный каталог, исключенный из VCS. Он привык храните медиа / статические файлы и базу данных sqlite во время разработки. Все в tmp можно удалить в любое время без каких-либо проблемы.
Virtualenv
предпочитаю virtualenvwrapper
и поставить все venvs в ,
но вы можете поместить его внутри tmp/
чтобы держать его вместе.
шаблон проекта
я создал шаблон проекта для этой установки, django-старт-шаблон
развертывание
развертывание этого проекта следующее:
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]
app, который позволяет мне запускать одну команду управления для обновления среды, но я использовал его только для одного проекта, и я все еще экспериментирую с ним.
эскизы и проекты
проект шаблонов я размещаю внутри global . Я думаю можно создать папку sketches/
в корне проекта, но еще не использовал его.
Pluggable применение
эти приложения обычно готовятся к публикации с открытым исходным кодом. Я привел пример. ниже Джанго-форме
~/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. После установки второго необходимо настроить рабочий каталог. Мой на моем /главная/envs каталог, как рекомендуется в руководстве по установке virtualenvwrapper. Но я не думаю, что самое главное, где он находится. Самое главное при работе с виртуальные среды сохраняют требования.txt файл в актуальном состоянии.
pip freeze -l > requirements.txt
Статический Корень
Папка проекта
Media Root
Папка проекта
README
Репозиторий root
лицензия
Репозиторий root
документы
Корень хранилища. Это python пакеты могут помочь вам сделать проще mantaining ваш документация:
эскизы
примеры
база данных
мне не нравится создавать новый . Я просто добавляю файлы с именем 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, но обычно я помещаю их в .
вот что я следую в своей системе.
Все Проекты: есть каталог проектов в моей домашней папке то есть
~/projects
. Все проекты покоятся внутри него.Индивидуальному Проекту: Я следую шаблон стандартизированной структуры используется многими разработчиками под названием Джанго-скел для индивидуальных проектов. Он в основном заботится обо всех ваших статических файлах и носителях файлы и все.
виртуальная среда: у меня папка virtualenvs внутри моего дома для хранения всех виртуальных сред в системе, т. е.
~/virtualenvs
. Это дает мне гибкость что я знаю, какие все виртуальные среды у меня есть и могу легко использовать!--3-->
вышеуказанные 3 являются основными разделами моей рабочей среды.
все остальные части вы упомянули в основном зависят от проекта к проекту (т. е. можно использовать разные базы данных для разных проектов). Поэтому они должны жить в своих индивидуальных проектах.