как построить django из модулей settings.py?
Когда Вы устанавливаете новое django приложение, необходимо добавить/изменить settings.py модуль.
Для проекта я пытаюсь сделать тот модуль подпакетом Python и создать модуль для каждого приложения:
settings\
__init__.py
base.py
admin.py
feincms.py
...
Проблема, с которой мне противостоят, состоит в том, как объединить атрибуты settings.py (INSTALLED_APPS, например, является кортежем значений), которые получают значения в различных подмодулях?
Спасибо
Хорошо, я задал неправильный вопрос (получил правильный ответ для него хотя). Мой вопрос должен был быть, как получить атрибуты от всех подмодулей и объединить их? Django импортирует настройки и ожидает, что все будет там.
6 ответов
Вы можете заинтересовать это решение ; Использует Execfile () для загрузки серии файлов настроек в порядке, где каждый файл имеет полный доступ к настройкам из ранее загруженных файлов, чтобы обновить, модифицировать и т. Д.
Предположительно, лучший способ «объединить» варьируется, атрибуты по атрибутам. Например, дано несколько кортежей (из установленных_apps различных подмодулей), вы можете просто объединить их в новую кортеж (для атрибута ATTRED_APPS пакета в целом) или , Если возможные дублирования - это проблема, поэтому что-то умнее удалить дубликации (в этом случае, вы можете не заботиться о заказе, поэтому просто кортеж (набор (TUP1 + TUP2 + TUP3)) может быть достаточно).
Для других случаев («объединение» словари, «объединение» настроек, которые являются просто скалярными или строками и т. Д.) Вам понадобятся разные стратегии (возможно, последовательные .update призывает к словарям, выбирать только один Согласно некоторым критериям скаляров или струн, и т. Д.) - Я просто не вижу «один размер подходит для всех» подхода.
«При установке нового приложения Django вы должны добавить / изменить ваши настройки. Панель модуля».
Я думаю, что это нормально, как есть.
Я не вижу никаких причин, чтобы изменить или изменять это вообще.
То, что мы делаем, - это «подкласс» модуль основных настроек.
Наши конкретные разработчики и установочные файлы имеют такие имена, такие как settings_devxy_linux2 и settings_checkout_win32 и т. Д.
Каждый из этих файлов начинается с из настроек импорта * Чтобы импортировать настройки основных и продлить эти основные настройки с переопределениями для определенной установки и платформы.
Это не требует никакой реальной работы. Это, однако, означает, что мы делаем большинство вещей с django-admin.py , потому что наши настройки не называются настройками .
Я использовал эту работу - вокруг:
settings.py :
INSTALLED_APPS = ('whatever',)
import more_settings
more_settings.modify(globals())
more_settings.py :
def modify(settings):
settings['INSTALLED_APPS'] += ('another_app',)
Если вы предпочитаете больше магии, чем в моем предыдущем more_settings.modify () Подход, попробуйте следующее:
STATIONS.PY :
INSTALLED_APPS = ('whatever',)
import more_settings
more_settings.modify(globals())
MOTE_SETTION.PY :
def config(INSTALLED_APPS=(), **other_settings):
INSTALLED_APPS += ('another_app',)
del other_settings
return locals()
def modify(settings):
settings.update(config(**settings))
Плюсы: Нет необходимости ссылаться на настройки с обозначением Dict
Минусы: должны определить модифицированные настройки в виде Kwargs для CONFIG ()
просто положите
from base import *
from admin import *
...
в ur init.py это должно работать
я использовал это для разных сайтов
base/settings.py # common settings: db, apps, ...
base/sites/website1/settings.py # site_id, custom middleware
base/sites/website2/settings.py # site_id, custom middleware
настройки сайта импортируют общие настройки с
from base.settings import *
и определяют пользовательские атрибуты