Лучшая практика для рабочей структуры каталогов проекта Django
Я знаю, что на самом деле нет единственного правильного пути. Однако я обнаружил, что трудно создать структуру каталогов, которая хорошо работает и остается чистой для каждого разработчика и администратора. Существует некоторая стандартная структура в большинстве проектов на github. Но он не показывает способ организации других файлов и всех проектов на ПК.
какой самый удобный способ организовать все эти каталоги на машине разработки? Как вы их называете, и как вы подключаетесь и развертываете это к серверу?
- проекты (все проекты, над которыми вы работаете)
- исходные файлы (само приложение)
- рабочая копия репозитория (я использую git)
- виртуальная среда (я предпочитаю размещать это рядом с проектом)
- статический корень (для скомпилированных статических файлов)
- корень носителя (для загруженных носителей файлы)
- 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
и переопределить только нужные переменные.для каждой среды существуют отдельные файлы настроек, например. производство, развитие. Я некоторые проекты у меня также тестирование (для test runner), постановка (как проверка перед окончательным развертыванием) и heroku (для развертывания в heroku) настройки.
требования
я скорее указываю требования в setup.py напрямую. Только те, которые необходимы для среда разработки / тестирования у меня есть
requirements_dev.txt
.некоторые услуги (например. в Heroku) требует, чтобы
requirements.txt
в корневом каталоге.
setup.py
полезно при развертывании проекта с помощью
setuptools
. Он добавляетmanage.py
доPATH
, так что я могу запуститьmanage.py
напрямую (в любом месте).приложения для конкретных проектов
я использовал, чтобы положить эти приложения в
project_name/apps/
каталог и импортировать их использование относительного импорта.Templates / static / locale / tests files
I поместите эти шаблоны и статические файлы в глобальный каталог templates/static, а не внутри каждого приложения. Эти файлы обычно редактируются людьми, которые не заботятся о коде проекта структура или питон вообще. Если вы являетесь разработчиком полного стека, работающим в одиночку или в небольшой команде вы можете создавать шаблоны для каждого приложения/статический каталог. Это действительно просто вопрос вкуса.
то же самое относится и к локали, хотя иногда удобно создавать отдельные локали справочник.
тесты обычно лучше размещать внутри каждого приложения, но обычно их много интеграция / функциональные тесты, которые тестируют больше приложений, работающих вместе, поэтому глобальные каталог тестов имеет смысл.
каталог Tmp
в корне проекта есть временный каталог, исключенный из VCS. Он используется для храните медиа / статические файлы и базу данных sqlite во время разработки. Все в ТМП может быть удален в любое время без каких-либо проблемы.
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]
приложение, которое позволяет мне запускать одну команду управления для обновления среды, но я использовал его только для одного проекта, и я все еще экспериментирую с ним.эскизы и проекты
проект шаблонов я размещаю внутри global . Я думаю можно создать папку
sketches/
в корне проекта, но еще не использовали его.Pluggable применение
эти приложения обычно готовятся к публикации с открытым исходным кодом. Я взял пример ниже от 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
Статический Корень
Папка проектаMedia Root
Папка проектаREADME
Корень репозиториялицензия
Корень репозиториядокументы
Корень хранилища. Этот пакет python может помочь вам облегчить сохраняя свой документация:эскизы
примеры
база данных
я не люблю создавать новые . Я просто добавляю файлы с именем
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
. Все проекты покоятся внутри него.Индивидуальному Проекту: Я следую за a стандартизированный шаблон структуры используется многими разработчиками под названием django-skel для индивидуальных проектов. В основном он берет на себя все ваши статические файлы и средств массовой информации файлы и все.
виртуальная среда: у меня папка virtualenvs внутри моего дома для хранения всех виртуальных сред в системе т. е.
~/virtualenvs
. Это дает мне гибкость что я знаю, что все виртуальные среды у меня и можете использоватьвыше 3 являются основными разделами моей рабочей среды.
все остальные части вы упомянули в основном зависят от проекта к проекту (т. е. можно использовать разные базы данных для разных проектов). Поэтому они должны жить в своих индивидуальных проектах.