Comments 12
Возможно, плохо искал.
Буквально в первых ссылках выдаёт довольно известный viper и китайский gookit/config.
Часть настроек была в .env, часть - в переменных окружения. Хотелось получить экземпляр одной структуры со всеми значениями, выполнив какую-то одну функцию
Для этого тоже есть пакеты, например caarlos0/env или hashicorp/go-envparse.
Идея состояла в том, что надо было просто указать несколько источников настроек и они бы собрались в единый экземпляр структуры. ...
Берём самые популярные источники данных: переменные окружения, .env, .ini, .json, .yaml - и начинаем писать. (Yaml пока отложил в сторону.)
Звучит прикольно, пока не начинаешь этим пользоваться. Когда проект конфигурируется больше чем из одного источника - это уже треш в плане отладки. А когда эти источники ещё и разный формат имеют - это просто превращается в помойку, в которой никто не разберётся.
Пожалуйста, ознакомьтесь с принятыми соглашениями в Go, по части:
Использования функциональных опций вместо строителя.
Использования any, вместо interface{}.
Именования файлов в пакетах в snake_case.
Количество уровней вложенности пугает.
Использования any, вместо interface{}.
Нет такого соглашения, any - это алиас для interface{}
Использования функциональных опций вместо строителя.
Такого тоже нет, а кто-то даже думает, что это анти-паттерн.
Именования файлов в пакетах в snake_case.
Как и такого. Можно как угодно называть файлы, а исключительные случаи вроде _test.go в документации описаны.
"ИМХО" и "мнение" - это совсем не тоже самое, что и соглашение
Более того, если соглашение ничем не подкреплено - линтером, компилятором и пр. то на него можно забить т.к. это в целом вкусовщина. А раз это вкусовщина, то пишите как хотите
Можно ознакомится с https://go.dev/doc/modules/layout и https://go.dev/doc/effective_go#package-names
Про именование файлов там ничего нет. А в именах пакетов, как написано, и snake_case не рекомендуется
мнение рандомного чела из интернетов
Так и ваши утверждения - такое же мнение рандомного чела (:
В го с этим как раз неплохо, потому что на нём просто писать кому угодно с каким угодно бэкграундом.
Да, есть effective go, но в целом пока код работает - нормальным людям совсем без разницы на то, что он не вписывается в придуманную ими модель идиоматичного го.
Вокальное меньшинство тех, кто ругается на то, как правильно надо, это зачастую люди, которые в го пришли с большим опытом ООП языков вроде джавы или до-диеза и оказалось, что го работает не так, как им привычно.
Вот сообщество раста как раз знаменито токсичностью и любителями гнобить за всё, что не по канонам.
расскажите плиз про:
Использования any, вместо interface{}.
Конечно, вот рекомендации от гугла по его использованию:
/go/decisions#use-any
Вот issue с соглашением о замене одного на другое в стандартной библиотеке:
/go/issues/49884
Почему каждая библиотека конфигурации на Go пытается делать всё сразу, притаскивая код или зависимости для форматов, которые не нужны в конкретном проекте? Явно же есть две задачи: 1) прочитать ключи и значения из env/file/whatever, 2) разложить значения по полям структуры конфига в соответствии с ключами. Достаточно определить что-то вроде type KV interface { Get(string) (string, bool) }, который возвращает библиотека, решающая первую задачу, и принимает библиотека, решающая вторую. Тогда для каждого источника достаточно было бы одной библиотеки, которую можно стандартным образом совместить с библиотекой-раскладывателем и другими библиотеками-источниками.
koanf </thread>
Я тоже кучу костылей на го написал. Тут тебе и апдейтер, и орм над орм, и сбор телеметрии. Но вот статьи об этом запилить не догадался
Собиратель конфигураций на Go