Comments 16
У меня вопрос-предложение. Вот Вы используете YAML для конфигурации, я тоже использую много где. Но, чем больше я использую YAML/JSON, etc. тем больше мне хочется заменить все это на задание конфига с помощью какого-нибудь скриптового языка, который и будет выдавать конфиг. Например, Python или что-то типа. Я к тому, что у YAML нет никакой семантики на этапе задания конфига, IDE пофиг, по сути, что вы на нем пишете. А если использовать готовый язык, то человеку проще, потому что IDE поддерживает. Генерировать можно уже и Protobuf/AVRO/etc. Обработка ошибок встроена в язык. Выглядит, что если не обмениваться информацией между гетерогенными системами, то нафиг оно не надо. По крайней мере, из всех наших продуктов мне очень хочется временами весь этот YAML выпилить к чертовой матери.
У вас довольно развитый конфиг и, возможно, станет еще более развитым. Не хотите попробовать сделать нормальный конфгуратор на базе тюринг-полного языка, не таща все в YAML?
Тоже столкнулся с подобной проблемой. В итоге хорошим решением оказалась генерация конфигурации с помощью JS/TS используя готовые классы. TS хорошо вточен в описание древовидных структур.
Появляется возможность например запросить данные с другого сервера для генерации конфигурации и тп.
Вобщем это хорощее и правильное решение
Но если есть язык для конфигурации пайплайна, то зачем тогда нужна конфигурация? Может проще действия сразу императивно скриптовать на предложенном удобном DSL?
Семантику можно добавить с помощью Json Schema... Можно ещё взять старое проверенное, не модное и молодёжное решение - XML+XSD, где семантика добавляется с меньшим количеством нетривиальных решений.
На уровне Schema довольно затруднительно делать проверку зависимостей в духе, если A, то не B, только базовую валидацию. Плюс динамически затруднительно из файла что-нибудь подставить, например, сертификат... Ну Вы поняли.
Но если есть язык для конфигурации пайплайна, то зачем тогда нужна конфигурация? Может проще действия сразу императивно скриптовать на предложенном удобном DSL?
Это уже вопрос вкусовщины, насколько надо упороться в DSL.
Вашу проблему хорошо решают визуальные конструкторы. Перетаскиваете мышкой стрелочки, затем выгружаете конфиг или просто копируете его.
Мою проблему хорошо решает и конфиг, заданный в тюринг-полном языке. Вопрос в том, что YAML/JSON плохо решает проблему, но почему-то все продолжают упарываться по ним с валидацией и репортингом ошибок в стиле "кровь из глаз". Я так-то YAML могу сгенерировать без проблем, о чем написал выше.
Вашу идею пытались реализовать уже много раз. Но всегда всё ломалось по одной из этих причин:
слишком сложно, чтобы запомнить (обычно пользователь помнит не более 5-7 типов)
слишком долго и неудобно, чтобы писать (типичная проблема передачи строк в командной строке, когда есть escape, есть escape-escape, есть многоуровневый escape...)
слишком сложно установить и запустить (что может быть хуже latex на windows?)
критичность ошибок и безопасность (почему бы просо не сделать eval(open('config.py','r','utf8').read())?)
В результате всё сводится к жёстким ограничениям возможностей, строгой типизации и исправлению ошибок.
p.s.
Кстати, вы читали статью про приколы yaml? Уверен, вы используете только 20% всех фич.
Типа такого https://dhall-lang.org/ ?
Уже давно применяю вместо .json конфиги как .js, который просто eval'ится. И комментарии к json и код можно затолкать и всё что угодно. Из минусов только то, что применяется это только с nodejs, и если потребуется конфиг прочитать другим языком это просто так не получится.
Это правда интересная мысль и я не первый раз о ней слышу. Но я не совсем понимаю, что ожидается от разработчиков софта, который нуждается в конфигурировании?
К примеру, есть желание написать конфиг на Python/Java/C/Go/etc. Как программе этот конфиг прочесть? Значит ли это, что разработчикам стоит предоставлять больше вариантов сериализации конфигов? Вроде тех, что Вы указали, там Protobuf/AVRO/etc.
Или же проблема в другом?
Можно и в YAML/JSON/что вам нравится. Вопрос просто в том, чтобы целевая аудитория не ковыряла семантически-сложные конфиги в YAML/JSON. Лучше бы им дать Default подход на каком-нибудь языке, где не заблудишься, а остальные по нужде напишут. В целом, я не настаиваю, что поставщик тулзы должен об этом думать... Просто, у Go есть тот же Otto, который, наверняка, должен отлично интегрироваться.
В целом, я не говорю как Вам поступать, скорее вопрос открытый - у нас тоже развитые YAML-ы, которые я хочу выкинуть что есть силы.
Что мешает в таком случае заменить конфиг на код? Скрипт подобного уровня ChatGPT нагенерит по запросу за несколько минут
у YAML нет никакой семантики на этапе задания конфига, IDE пофиг, по сути, что вы на нем пишете
Эту проблему решает json schema. Описывается формат файла, в IDE указывается, что у этого конфига вот этот файл схемы, и начинает работать автодополнение и валидация.
Я использую Pydantic для разбора и валидации конфига, и оказалось, что даже описывать не нужно, schema_json() выдает готовую схему, которую PyCharm подхватывает без проблем.
Спасибо за то, что поделились своим проектом. у меня тоже есть подобный, но ориентирован на шифрование и сжатие.
а вот как вопрос шифрования решается ? (и решается ли?)
Если есть задача зашифровать файл, то это может быть просто одна из операций в пайплайне.
Из решений, которые уже готовы, там можно запускать внешние команды. Без проблем должна запускаться, к примеру, gpg.
Еще можно написать такую операцию, если что-то специфическое. Новые операции там довольно легко интегрировать.
Делайте что угодно со своими файлами, ну почти