Вводная
Для всех последующих примеров кода предполагается, что выполнен импорт settings
from django.conf import settings
Проблема
Если мы захотим использовать какую-то из настроек django в своём коде без упоминания его в settings.py, то проблем не возникнет.
# Обычно никто не задаёт значение для CSRF_COOKIE_AGE,
print(settings.CSRF_COOKIE_AGE) # никаких ошибок, всё работает
Часто для своего приложения нужны свои настройки1. Чтобы приложение не упало из-за отсутствия настроек в settings.py нужны проверки и подстановка значения по умолчанию.
print(getattr(settings, 'MY_APP_PARAM_1', default_value_of_param_1))
Выглядит как-то не очень, но если учесть, что одна и та же настройка может использоваться в нескольких местах, то код преображается в нечто такое:
# my_app/conf.py
default = {
'MY_APP_PARAM_1': default_value_of_param_1,
# Представьте, что здесь перечислены остальные настройки
}
def get_param_value(param_name):
return getattr(settings, param_name, default_value_of_param_1)
# my_app/any_place.py
from .conf import get_param_value
print(get_param_value('MY_APP_PARAM_1')) # выглядит не очень, но работает
print(get_param_value('MY_APP_PARAM_L')) # IDE не помешает нам ошибиться
Хочется, чтобы работа с настройками была одинаковой для всех приложений, чтобы вид настройки был похож на settings.MY_APP_PARAM_1 и чтобы работало автодополнение.
Решение
Я не стал придумывать велосипед, а взял чужой. Подозреваю, что на просторах PyPi можно найти ещё с десяток, поэтому свой туда забрасывать не стал, хотя найти аналогичный мне там не удалось.
Скачать результат можно на github gist
Код в основном взят из django-rest-framework, из него выкинуто всё, что мешает переиспользованию. Файлик кладётся в папку доступную для всех приложений django. У меня это папка utils.
Посмотрим как это работает
# my_app\settings.py
from utils.django import AppSettings
# Описание настроек приложения.
# 1. Все поля находятся в одном месте
# 2. Видны все значения по умолчанию
# 3. При желании можно добавить типизацию
class MyAppSettings(AppSettings):
URL = ''
USER: str = ''
PASSWORD = ''
# Объект с инициализированными данными
# 1. Достаточно написать "conf." в любом IDE
# и редактор сам предложит название настройки
# 2. Все обращения приложения к настройкам должны
# происходить через этот объект, тогда не будет риска,
# что приложение "сломается" из-за внешних факторов
conf = MyAppSettings('MY_APP_CONF')
# django_project\settings.py
# ...
# Настройки Django-проекта
# 1. Могут быть заданны частично
# 2. Могут быть совсем не заданы
# 3. Могут быть заданы явно, без использования .env
MY_APP_CONF = {
'URL': env('MY_APP_URL', default=''),
'USER': env('MY_APP_USER', default=''),
'PASSWORD': env('MY_APP_PASSWORD', default=''),
}
# my_app\using.py
from .settings import conf
# Здесь создаётся условный клиент с подключением к некому сервису
client = get_data(conf.URL, conf.USER, conf.PASSWORD)
На что следует обратить внимание:
- Описание настроек приложения и значений по умолчанию делается очень просто.
- Все настройки приложения задаются в одном словаре, т.е. не будут размазаны по коду и не нужны префиксы к каждой настройке.
- Не нужны проверки на существование при использовании настроек. В худшем случае будет значение по умолчанию.
-
Я называю настройкой константу, которая влияет на поведение программы и значение которой можно задать в settings.py ↩
Top comments (2)
Дважды декларируются URL, USER, PASSWORDБ что есть неправильно
Правильно использовать декоратор
def apply_defaults(cls):
defaults = {
'default_value1':True,
'default_value2':True,
'default_value3':True,
}
for name, value in defaults.items():
setattr(cls, name, some_complex_init_function(value, ...))
return cls
@apply_defaults
class MyAppSettings(AppSettings):
pass
Спасибо за замечание.
К сожалению, предложенный тобой вариант не меняет ситуацию.
my_app\settings.pyтеперь выглядит по другому, ноdjango_project\settings.pyостался прежним, а значит дублирование осталось. При этом IDE "ослепнут", т.к. имена полей будут генерироваться динамически.