Ищу формат для древовидных/иерархических конфигов

XML

Я бы выбрал его, на самом деле. Либы под парсинг есть почти для любого языка.

Ну еще ini в голову пришел, но это как-то виндовенько. Да и не дерево тоже.

Не подходит по всем параметрам. Не для людей.

А xml для людей, ага.

Есть идеи?

Я делаю конфиги прямо на js. Какую-нибудь херню типа «a=>b,c» перевожу в стуктуру, чтобы с этим можно было работать.
Сделай сам, короче. Может выйдет что-то удачное, что все будут юзать.

JSON5 Ближе всего к идеалу, но малораспространён.

Этот твой руст тоже не распространён, но тебя абсолютно не смущает.

Всё равно YAML. Все осиливают и ты справишься.

Про проблемы с предугадать было бы интересно посмотреть примеры.

PS: шутки про s-expressions не интересны

а ведь идеально подходит

libconfig как вариант

Как будет распарсен данный текст?

list:
  - value1
    - value2

А такой?

list:
  - value1
- value2

А такой?

key1:
key2: value2

А xml для людей, ага.

Ну очень урезанный - да.

Я делаю конфиги прямо на js.

У меня их будут сотни. И нужно очень быстро их парсить. Я уже думал в виде питоновских скриптов хранить, но он слишком медленный.

Как некорректный.

Ты конфиг пишешь или парсер?

В иерархическом конфиге есть словарь и список. Напиши себе примеры: список списков, словарь списков, словарь словарей и список словарей. И из этих элементов строй конфиг.

А неправильное форматирование не ты должен отлавливать, а линтеры. Их миллион, выбери тот который соответствует библиотеке парсера, которую ты будешь использовать.

И нужно очень быстро их парсить.

Ну тогда вообще нужен бинарный формат.

Я уже думал в виде питоновских скриптов хранить, но он слишком медленный.

У тебя всё вычитывается 1 раз при запуске?

Как некорректный.

Шта?! Там некорректный только второй.

Ты конфиг пишешь или парсер?

Оба.

А неправильное форматирование не ты должен отлавливать, а линтеры.

Линтер тут не поможет.

Ну тогда вообще нужен бинарный формат.

Он для людей. Поэтому обязательно текстовый.

У тебя всё вычитывается 1 раз при запуске?

Да, типа компилятор. Прога его никогда не перезаписывает.

Ну и вишенка:

# comment
text: | # comment
  # not a comment

PS: А лор думает что коммент, лол.

Лор и на растовых лайфтаймах ломается.

Эта «вишенка» - очень полезная фича, да.

И всё равно непонятно зачем ты лезешь в детали форматирования, когда как тебе надо написать конфиг, прочитать его, и задокументировать используемые имена параметров.

Эта задача сильно уже, чем написание полноценного парсера ямла со всем набором фич и corner-case.

Я пишу конфиг - скармливаю его парсеру - получаю какую-то ересь на выходе. Действительно, зачем мне «детали форматирования».

Бери XML. Урежь его по самый небалуй c помощью XSD схемы. Так ещё и провалидируешь сразу что там руками понаписали.

XML слишком жирный.

Для валидации у меня есть serde.

Жирный для задачи? Ну предлагаю же — ограничить использование по самый не балуй с помощью XSD. Шаг влево-вправо — расстрел на месте с указанием номера строки и символа. Если что понадобится расширить — правишь XSD и вуаля.

Жирный сам по себе. Вот сравнение на реальном конфиге:

YAML

# Integer overflow.
- table: glyf
  glyphs:
    - name: A
      type: contours
      contours:
        - contour:
          - { x: 32767, y: 0 }
          - { x: 65534, y: 0 }
          - { x: 98301, y: 0 }
          - { x: 131068, y: 0 }

XML

<!-- Integer overflow. -->
<tables>
    <table name="glyf">
        <glyphs>
            <glyph name="A" type="contours">
                <contour>
                    <point x="32767" y="0"/>
                    <point x="65534" y="0"/>
                    <point x="98301" y="0"/>
                    <point x="131068" y="0"/>
                </contour>
            </glyph>
        </glyphs>
    </table>
</tables>

JSON5

// Integer overflow.
[
    {
        table: "glyf",
        glyphs: [
            {
                name: "A",
                type: "contours",
                contours: [
                    [
                        { x: 32767, y: 0 },
                        { x: 65534, y: 0 },
                        { x: 98301, y: 0 },
                        { x: 131068, y: 0 },
                    ]
                ]
            }
        ]
    }
]

PS: Тот случай, когда json самый унылый.

Ну то есть вместо того чтобы сесть и написать один раз простой валидный yaml, с четкой структурой, правильными отступами, без пустых ключей и нетривиальных прочтений, ты решил поискать другие форматы и технологии.

Прокрастинация как она есть.

То есть вы согласны что YAML не очевиден и без линтера никак. Ок.

Ну и это, прочтите пост. Речь идёт про написание сотни конфигов обычными людьми. Не только я их писать буду.

Тебе самому ямл не заходит. Зачем себя мучать? Мне нравится, из трёх представленных, как выглядит XML.

Он до безобразия переусложнён и не очевиден.

Тут не хватает вот этой ссылки: https://twitter.com/chrisjrn/status/1232016100038266880

YAML самый читаемый, ценой переусложнения парсинга. Что приводит к тонне нюансов.

Мне нужен конфиг, который так же легко читать как YAML, и так же легко парсить как json.

Скорее этих:

• https://github.com/cblp/yaml-sucks
• https://hitchdev.com/strictyaml/#design-justifications

Я согласна что в ямле есть возможность найти себе развлечений.

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

Если использования конфига начинается с описания того, что делать нельзя - это плохой конфиг.

Использование конфига начинается с копипаста дефолтного конфига.

Советский автопром начинается с копипасты европейского автопрома.

Вообще не аргумент.

шутки про s-expressions не интересны

Чорт, ну а серьёзно, почему не рассматриваешь?

У меня «конфиг» может быть метров 10. Не вариант.

Если серьезно, то я и так использую кастомный yaml-парсер, который пропускает только то, что я хочу. Но это говорит не в пользу yaml.

Ищу формат для древовидных/иерархических конфигов (комментарий)

У меня «конфиг» может быть метров 10

Это не конфиг.

Понятное дело не надо давать пользователю в качестве шаблона дамп всего состояния. Но какой-то дефолтный конфиг с типичными параметрами и типичным форматированием сделать не проблема.

Но это говорит не в пользу yaml.

А у тебя задача в этом треде yaml поругать или выбрать оптимальное решение? Я не говорю что yaml идеален и у него нет проблем, если что.

Lua

У меня «конфиг» может быть метров 10.

Хоть ты и ссылаешься на рис.1, но ведь ты же просто изобретаешь свой ЛИСП с костылями. Бери тогда xml - это идеальный костыль для dsl, проверенный временем и ынтерпрайзом.

Между прочим, xml парсится медленнее json (например, здесь).

И?

Мы пишем на Play, так что основным форматом конфигов является HOCON. Посмотри, может, тебе подойдёт.

ТС уже два часа рассказывает про то, что ему нужно быстро парсить конфиги, и конфигов много.

А почему в списке нет православного RON, вы же чуть ли не главный продвиженец Rust на лоре, он вроде вполне себе древовидный…

Посмотрел - такой себе json на стероидах. Тогда уж лучше json5.

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

Там глубокая альфа.

Быстро, по сравнению с запуском питона на каждый чих.

Лор и на растовых лайфтаймах ломается.

Это не ЛОР ломается, а highlight.js.

Это не

--> Ищу формат для древовидных/иерархических конфигов (комментарий) <--

XML не для людей. По теме JSON

Так json не для людей.

Для людей GUI-настройки, а не вот это все.