Антипаттерн settings.py

Я все ждал пока ты проведешь аналогию между settins.py и синглтоном и из нее выведешь гуся почему это все плохо, но так тоже хорошо получилось.

Только про инъекции без примера будет понятно только для тех, кто уже в теме

Яблоко шикарное.

Андрей Светлов буквально вчера написал статейку на близкую тему.

Вы серьезно?

Приведите, пожалуйста, в качестве примера, решение проблемы с SOME_JOB_COMMAND предложенным вами способом.

Как бы залог хорошей статьи — это для начала проанализировать существующие решения, если они интересны — рассказать о них, на забыв при этом заглянуть в документацию и гайды на официальном сайте.

Из непосредственно решений щупал:
django-config правда там есть свои проблемки с переписыванием manage.py и config.py
А так же django-configurator не решает части описанных проблем, зато предоставляет удобный модульный конфиг для приложений.

Подробный гайд с рассмотрением проблемы:
code.djangoproject.com/wiki/SplitSettings

нет

Понимаете в чём проблема? То, что мы перекрыли значение PROJECT_HOSTNAME абсолютно по барабану для итогового значения SOME_JOB_COMMAND.

В предложенном вами способе SOME_JOB_COMMAND все равно останется в выполняемом коде и поэтому данную константу невозможно будет переопределить. В таком случае, если условиться, что SOME_JOB_COMMAND не подлежит переопределению, то данная проблема легко решается в рамках settings.py:

# settings.py

BASE_PATH = os.path.dirname(__file__)
PROJECT_HOSTNAME = 'localhost'

try:
    from settings_local import *
except ImportError:
    pass

SOME_JOB_COMMAND = '%s/bin/do_job.py -H %s' % (BASE_PATH, PROJECT_HOSTNAME)

Мы могли бы скрипя зубами скопипастить определение SOME_JOB_COMMAND после перекрытия, но даже это не возможно: BASE_PATH то, в другом модуле.

# settings_local.py
from settings import *

Вот тут, собственно, я искренне пытался решить сферичиский пипец с конфигами в группе довольно крупных джанго-проектов. Вот интересно, как бы вы решили эту проблему?

P.S. Это не мой код! Я бы до такого не додумался…

1. «все дружно из произвольных мест лезут в волшебный недомодуль settings за своими константами»

Строго говоря, в django никто не лезет в settings.py проекта за константами. django.conf.settings — это экземпляр класса LazySettings (обертка над классом Settings).

2. В разделе про исполняемый код было 2 конкретных аргумента.

Аргумент 1: сложность переопределения вычисляемых значений. Это совсем не проблема, решение тут очевидное: вычисляемые значения вычислять после импорта settings_local.py.

# значения по умолчанию
from settings_local import *
# вычисляемые значения

Аргумент 2:

Я уже не говорю о том, что исполняемый код в качестве конфигурации может просто приводить к трудноотлаживаемым ImportError при старте приложения в новой среде.

Можно пример? Если в settings.py синтаксическая ошибка, то будет нормальный трейс с номером строки. Если указана неверная настройка, то будет одинаковая ошибка что в случае ini файла, что в случае settings.py, какая разница, где настройке лежать.

3. High-coupling. Во-первых, назначение сущности «проект» как раз в том, чтобы связать различные части (которые сами по себе слабо связанные, в идеале) между собой.

Замечание про VK_API_KEY — справедливое, но оно совершенно не имеет отношения к тому, куда будет помещена опция: в ini-файл или в settings.py. Ваше решение эту проблему не решает никак. Эту проблему решает только здравый смысл — программистам стоит думать, когда упрощение конфигурации за счет выноса константы в глобальные настройки стоит снижения гибкости, а когда нет.

4. Хранение настроек в ini-файлах (или как угодно) можно легко реализовать в settings.py: создаем там ConfigObj, парсим, что нужно. Этому ну совсем ничего не мешает. А вот чтобы хранить произвольные настройки в .ini, .yaml или каком-то другом формате, нужно будет выдумывать всяческие костыли. Как хранить set в YAML? Как хранить массив в ini? А если настройка — callable (например, функция для транслитерации к какому-нибудь AutoSlugField)?

Заметьте, то, что, мол, не должно быть callable-настроек, — не аргумент. Они могут иметь смысл и быть простыми. По крайней мере, проще, чем вложенные словари. Запретим вложенные словари? Как решить, что должно быть, а что нет? В пределе получаем, что настроек не должно быть совсем. А должен быть файл, который разные части создает и конфигурирует как нужно. Угу, и получаем опять settings.py, но раздутый в несколько раз конфигурирующим кодом.

Хитрую подгрузку, иерархию и тд — тоже несложно реализовать, если она вдруг нужна (кстати, зачем?).

Суть паттерна «settings.py» в том, что он дает гибкость и не мешает ничему, а не в тех ограничениях, которые в статье ему незаслуженно приписываете.

Классный антипаттерн, используется очень много где — это не болезнь питона… phpMyAdmin, Drupal… over 9000 других программ!

(1) Ну хорошо хоть там есть LazySettings. Когда django-style решение слизывают в других проектах, обычно не заморачиваются над такими мелочами.

(2) А если в settings_local хочется таки определить итоговое значение и чтобы оно потом не перетёрлось? Можно, конечно if 'BLAH_BLAH' not in locals():, но ugly же. Пример с ImportError чуть выше — циклический импорт.

(3) У вас все проекты заключаются лишь в связывании готовых частей? Везёт вам.

А про VK_API_KEY — всё так, дело не совсем в настройках. Но если они оформлены в виде модуля, прям возникает соблазн использовать их напрямую. Когда всё лежит в ini при имплементации VkontakteProfileCache внутренний голос спросит: «А точно я именно тут должен заниматься парсеньем настроек? Ведь класс не о том»

(4) А зачем одновременно иметь и settings.py и ConfigObj? Для dotted-access style notation? Можно ведь объект-конфигурацию унаследовать от базового и дополнить всеми нужными ништяками. В том числе и callable настройками.

А существует хороший путь интеграции этой бадяги в джанго?

Тут самое главное — не сделать из django очередной java-фрейморк с xml-файлами для настроек. Накосячить можно и там и там. Это уже проходили.

Самое главное — если есть у конкретного продукта некая эко-система — то не стоит вот так сразу пытаться её сломать. В вашем случае получается 2 файла настроек: settings.py и ещё ini-файл. Путаница возникает. Что? Где? Почему именно там?

Было: «Будьте добры иметь в корне settings.py с определёнными FOO_BAR, FOO_BAZ и FOO_QWE», стало «Будьте добры иметь парсер и передавать результат парсинга некого конфига». Чо-та не сильно связанность уменьшилась, не?

в нормальных проектах пишут как getattr(settings, 'FOO_BAR', default_value), так-что проблема «обязательно иметь» скорее надумана.

А это тут причём? При таком подходе главный ужас будет в конфиге, а не при импорте.
Я говорю о том, что объект settings должен где-то из чего-то создаваться и, в идеале, быть словарём. И при этом я не говорю где и из чего.

По поводу вычисляемых параметров можно сделать так: взять класс (например config), и при обращении к переменным проверять не являются ли они функцией, если же функция — то вычислять и отдавать уже сам результат, т.к. как-то так:

Config.PROJECT_HOSTNAME = 'localhost'
Config.SOME_JOB_COMMAND = lamda cfg: '%s/bin/do_job.py -H %s' % (cfg.BASE_PATH, cfg.PROJECT_HOSTNAME)
Config.PROJECT_HOSTNAME = 'somehost'

Какое бурное обсуждение!
А я всегда считал, что бесполезно мешать программисту выстрелить себе в ногу — если он этого так жаждет.
Неблагодарное это дело. Разработчики — люди изобретательные. Они все равно сумеют обойти все ограничения и с наслаждением разрядят ружжо в свою конечность.

Архитектурные космонавты детектед.