Comments 2
Я так и не понял, какую проблему решаем-то?
Если хочется распихать настройки по нескольким файлам, чем стандартное from .database import * не угодило?
Если хочется отдельные настройки для разных окружений, чем local_settings.py не угодил? Ну и создавать settings/prod.py и settings/test.py тоже никто не запрещает и без использования сторонних библиотек
следующий файл видит всё, что объявили предыдущие
один компонент начинает дополнять словарь из другого, и получаем плавающий startup-баг
Во-первых, а зачем? Во-вторых, это гарантированно ломает линтеры, потому что они не в курсе, что кто-то там подменяет namespace. По-моему вы просто создаёте себе проблемы на ровном месте
Да, тут согласен — просто разнести настройки по файлам можно и без библиотеки.
Здесь удобство в том, что файлы собираются в одном пространстве имён: следующий уже видит настройки предыдущего. Но это же и минус — зависимости становятся не такими очевидными, а линтер сам не догадается, откуда появилась переменная. Так что да, тут замечание к месту
Про «плавающий баг» я тоже неудачно написал. При явно заданном порядке ничего само по себе плавать не будет. Проблемы начинаются, когда этот порядок поменяли, а где-то осталась неявная зависимость.
В общем, это не обязательный инструмент и не замена нормальной организации настроек. Скорее один из вариантов со своими удобствами и недостатками. Если обычные импорты уже устраивают, то особого смысла тащить библиотеку нет.
Один `settings.py` на всё больше не работает: наводим порядок в настройках Django