Антон, я тебя не понимаю:

> У тебя должно быть ровно одно место для декларации конфига, его типа и дефолтного значения. И это место может быть  ямл файл, а не код. Получается что ямл это аналог dsl и является частью кода.

Каким образом в ямле ты можешь определить значение по умолчанию. А переопределять ты где и как будешь? Это текстовый файл же, а не нечто исполняемое.

А про ровно одно место никто и не спорит.

> devops'у не надо лезть в код искать какой то параметр, его дефолтное значение и прочее. Ему достаточно открыть один конфиг файл. В этом же yamlе могут быть и комментарии.

Ровно это же я могу сказать про settings.py 🤷

> Если нужно сделать параметр, для которого нет универсального значения, и которое нужно обязательно определять, то можешь его поменить строкой определенной.

И как это сделать в ямле? В текстовом файле.

> И во время сборки (всмысле кнопки в CI, а не docker build) проверять (ну да, надо чекер написать из пяти строк) конфиг. И если девосп забудет (или ему забудут сказать) определить этот параметр, то об этом девопс узнает до момента начала деплоя.

Ну да, вместо os.getenv("ENV", default_value) надо просто использовать os.environ["ENV"]

> А еще, иногда, конфиги меняют QAщики. Напримрер через конфиг можно включать/выключать какие то фичи. И для QAщики поменять конфиг, а не код, это меньший стресс и вероятность ошибок меньше (но тут надо не забыть объяснить QAщику разницу между табами и пробелами и выключить автоматическую конверсию).

Чем это лучше, чем передать переменную окружения-то? Универсальное средство же

> Хранить секреты в волте и передавать их только через переменные окружения (чтобы враг их не узнал), это прям секрет полишинеля. Получить доступ к переменным окружения не сложнее, чем к файлу.

Эти секреты нужны, чтобы разделить приложение, общую конфигурацию (открытую) и секретные значения, к которым доступ контроллируется. Если ты из этих секретов через шаблон генерируешь конфиг и кладешь его куда-то, то по безопасности это да, примерно то же самое, что и передавать через переменные окружения.

Мой поинт в том, что не нужно смешивать разные консерны. Хранение секретов != хранению конфигурации. Вполне допустимо хранить конфиги, куда секреты прокидываются извне. Вполне допустимо хранить в том же репозитории секреты, которые менеджатся через тот же sops.

> То, что ты описал, с промежтуочным ямлом, это безусловная дичь и рукожопие.
угу, но только так повсеместно делают..

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

> Каким образом в ямле ты можешь определить значение по умолчанию.
Просто у тебя есть yaml который идёт с кодом в котором как раз дефолтные значения которые задаются разработчиком, и отдельно файл для каждой инсталяции, в котором перечислены только то что нужно изменить.

> Ну да, вместо os.getenv("ENV", default_value) надо просто использовать os.environ["ENV"]
Не получится. Тебе надо собрать нужный контейнер, его задеплоить, скормить ему все переменные окружения и уже в нём как то запустить import settings.py

> Чем это лучше, чем передать переменную окружения-то?
ты через переменную окружения можешь передать только строку. Если тебе нужен масив / словарь и т.д., то сразу начинаются пляски. Зачем себя ограничивать то?

> Мой поинт в том, что не нужно смешивать разные консерны.
тут согласен.

settings.py плох тем, что разработчик начинает туда вкрячивать код который начинает парсить переменные окружения, чтобы получить из строки массив, добавлять кучу логики (а иногда и в базу ходит -- и такое я видел) и т.д
чтобы завалидировать settings.py тебе нужно полноценный питон с полноценным проектом (не редкость в нём есть импорты).

И на практике, получается схема примерно такая:
* devops подготавливает yaml файл
* пишет код который yaml превратит в env файл
* разработчик использует dotenv или вручную переменные окружения конвертит в структуры питона

А я предлагаю использовать сразу yaml файл, без промежуточных этапов.

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

угу, а также не дают внедрить sentry, request_id, запуск unittestов в тимсити, CD, централизованный сбор логов и ну и всякой фигни по мелочи...

угу, а также не дают внедрить sentry, request_id, запуск unittestов в тимсити, CD, централизованный сбор логов и ну и всякой фигни по мелочи...

если бы я отвечал за всю систему, то да.. А так, я мелкий микросервис пилю стороннему заказчику под его полным руководством. в понедельник буду другой пилить. Ну было пару проблем, который не было бы, если был сентри и CD. Но солдат спит, служба идет (с).
То есть не эффективность меня  раздражает, но у меня сон нормальный и если ёбнется прод (а он уже пару раз того, один раз во время корпоратива моего :-)  ), то это не моя попаболь.
и да тут, адмыны держать конфиги у себя в репе в yamlе, и для каждого сервиса *вручную* собирают env файл. Когда нибудь потом будет скрипт который yaml будет в env для каждого микросервиса делать.
Ах да, с безопасностью тут тоже на уровне, да так, что почти никто не пользуется внутренней почтой :-)  Поэтому когда кто то комментриует ПР в локальном битбакете, то дублируется инфа в телеге, ибо почту проверяют в лучшем случае раз в день :-).

Я держусь из последних сил, чтобы не назвать имя этой организации (наверное это NDA), чтобы вы держались подальше от неё.

Эх, а меня сейчас продакшен работает с утра до 6 вечера и все :) пока все спят, и процессов никаких не происходит, а если что-то падает то фиксится в рамках рабочего дня

Всё по классике - сначала придумать полезную штуку для всех. Но сделать её настолько сложной, что-бы без дополнительных платных услуг было сложно её правильно использовать (как законы и юристы).