Comments 11
неплохой костыль, а то свои надоели уже :)
https://pypi.org/project/dynaconf/ рассматривали? Уже более 6 лет проекту, функционал — тот же, что и в статье, а также ещё немало полезного. Например, может из Hashicorp Vault брать конфиг.
Эту библиотеку не рассматривал, спасибо! Обращу внимание, что предложенное решение более легковестно (меньше зависимостей) и хорошо подходит для небольших проектов. Но радует, что есть и альтернативы
Вот за это отедльное спасибо. самый кастилинг начинался как раз с валтом;
dynaconf офигенен. Хотя там полгода назад была пара неприятных багов. И не хватало пары возможностей. Тут я попробовал добавить указание путей с помощью Path https://github.com/mk-dv/dynaconf-pathlib.Path/commit/83d9c9d8f6ca574474d3846a7687a0c9fa412fb5
Но к сожалению времени на mr не оставалось - искал свою первую работу джуном=)
И еще я находил там баг при парсинге вложенного списка в yaml, и даже исправил его локально(в мастере его так и не поправили). Но в целом - решение великолепное, на голову выше десятков других решений что я перебрал.
Если используете pydantic, то у него есть свой класс для настроек: https://pydantic-docs.helpmanual.io/usage/settings/ . Довольно удобно, если пользуетесь Docker/Kubernetes - настройки автоматом подтягиваются из environment и раскладываются по нужным типам с валидацией значений.
Для проектов на компилируемых языках конфигурация -- это код, выполнение которого отсрочено от времени компиляции до времени выполнения. В динамических языках компиляция не отделяется от выполнения, поэтому и нет нужды хранить конфигурацию в каком-то особом формате. Разве что за исключением совсем сложных случаев, вроде того же Vault. А всякие JSON, XML, YAML, ini, env и т. д. попадают в проекты на Python по недоразумению
Конфиги могут быть для пользователей. Они не обязательно должны быть знакомы с нюансами ваших языков программирования. Ошибки в конфигурации должны обрабатываться иначе, нежели ошибки в программном коде. В таком случае это скорее входные данные, чем код. Почему бы не использовать форматы, предназначенные для данных?
Конфиги могут быть для пользователей. Они не обязательно должны быть знакомы с нюансами ваших языков программирования.
В простых конфигах нет никаких нюансов, кроме "имя = значение". Исключения, опять же, могут быть, вроде Forth с обратной польской нотацией, но в большинстве случаев для непрограммиста что присваивание в Python, что "ключ-значение" в ini-файле -- разницы нет.
Если же конфиг по ходу дела становится сложным, появляется шаблонизация, переменные, макросы и т. д., то "формат данных" превращается в доморощенный язык программирования. Скорее всего даже Тьюринг-полный, зато непопулярный, плохо документированный и глючный. Всё ещё не видите проблемы?
Ошибки в конфигурации должны обрабатываться иначе, нежели ошибки в программном коде.
И это в любом случае остаётся на совести программиста. Иначе пользователю без разницы, откуда вылез стек-трейс: из парсера формата данных или из самого интерпретатора.
В таком случае это скорее входные данные, чем код. Почему бы не использовать форматы, предназначенные для данных?
Разница между кодом и данными может казаться призрачной (Lisp!). Мне проще всего объяснить, почему конфигурация -- это код, а не данные, с помощью правила "ноль-один-бесконечность". Нам на практике интересен только ограниченнный набор "корректных" конфигураций, но при этом мы заинтересованы корректно обрабатывать бесконечное разнообразие данных.
Почему формат данных плохо подходит для кода, я, надеюсь, уже объяснил.
жуть, сколько неявного плодить на ровном месте для чтения конфига. посмотрите на pydantic, он вам и провалилирует и структура заранее известна и описана в коде а не в ямле, и словарь приготовит если надо и переменные окружения прочитает
Действительно, любопытный пример "чистого, типизированного, расширяемого python кода"
Python: конфигурация проекта без боли