LINUX.ORG.RU

С какими форматами конфигурационных файлов вам приятно работать как пользователю?

 


0

2

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

Опрос в контексте использования готового ПО, а не разработки.

  1. INI 334 (57%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. JSON 218 (37%)

    ****************************************************************************************************************************************************************************************************************

  3. YAML 215 (37%)

    *************************************************************************************************************************************************************************************************************

  4. TOML 102 (17%)

    *************************************************************************************************

  5. XML 87 (15%)

    ***********************************************************************************

  6. Самописные 67 (11%)

    ****************************************************************

  7. Никаких конфигов, только UI! 49 (8%)

    **********************************************

  8. Для этого должны быть CLI утилиты 43 (7%)

    *****************************************

  9. Свой вариант (укажите в комментариях) 27 (5%)

    *************************

  10. Реестр Windows 21 (4%)

    ********************

  11. SQLite (и другие embedded DB) 21 (4%)

    ********************

  12. Специализированные библиотеки (libConfuse, libconfig, etc) 20 (3%)

    *******************

Всего голосов: 1204, всего проголосовавших: 583

★★★

Проверено: Satori ()
Последнее исправление: hobbit (всего исправлений: 2)

Ответ на: комментарий от Pravorskyi

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

Это-то понятно. Но тогда правильнее говорить не о самих специализированных библиотеках, а о форматах файлов этих библиотек.

Погуглил. Форматы libconfig и libConfuse похожи на несколько усовершенствованный JSON (с первого взгляда даже не совсем бросается в глаза, чем они отличаются от последнего).

hobbit ★★★★★
()

Какие конфиг файлы в линуксе? В линуксе обычный текстовый файл и есть конфиг

burato ★★★★★
()
Ответ на: комментарий от burato

Текстовые файлы бывают разными, XML и JSON — тоже текст.

hobbit ★★★★★
()

Пока что для меня идеал – TOML. Простой и понятный. Пытался до этого приобщится к YAML да всё никак, вроде пытается казаться «human-readable», но как начнешь писать конфиги на нем, все превращается в ад с этими ублюдскими отступами. Собственно, я его и рассматриваю как максимум как язык разметки, не более. Да и он особо и не позиционируется как язык конфигов, поэтому не пойму, почему все так с ним носятся.

Unicode4all ★★★★★
()
Ответ на: комментарий от eternal_sorrow

Значит не все библиотеки-парсеры это умеют - я делал замену всех пробелов - не помогало

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

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

Так конфиги и не должны быть сложным случаем. Если конфиг сложный, значит кто то накосячил.

kirill_rrr ★★★★★
()

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

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от ergo

json для конфига не годится ввиду невозможности комментирования

Если очень хочется, то можно.

no-such-file ★★★★★
()

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

stargrave
()
Ответ на: комментарий от annulen

Этот есть.

Я уже выше писал что избегаю XML.

mord0d ★★★★★
()

ini только в самом простом случае, когда нет структуры. Даже без [разделов], только key = value. А так YAML и только он. Замечательный универсальный гибкий формат. Хотя вообще ещё неплох protobuf text format, но его редко используют.

slovazap ★★★★★
()
Последнее исправление: slovazap (всего исправлений: 1)

Любые текстовые. Никакой бинарщины.

drfaust ★★★★★
()

Ничто из выше перечисленного.
Лучше всего env-переменные и папочка с env-файлами, как вот с profile.d, ну или если очень хочеться прям конфиг, то HOCON.

Ну или если проект на скриптовом языке, типа Ruby или Python (я работал например с Vagrant и Django), то конфиг должен быть просто текстовый файл с константами на этом же языке.

Всё остальное не удобно автоматизировать.

sphericalhorse ★★★★★
()
Последнее исправление: sphericalhorse (всего исправлений: 2)
Ответ на: комментарий от t184256

ограждает меня от всех этих ужасов из шапки

это если тебе не придется оверрайдить какой-нибудь fontconfig, тогда ты будешь писать xml прямо в твоем Nix-конфиге ☺

Minona ★★☆
()

YAML.

Замечательный универсальный гибкий формат.

Или, внезапно, реестр (не Windows, конечно. Dconf со встроенными схемами и валидацией, ня).

Всё остальное — либо не имеет иерархичности, либо вырвиглазно (XML), либо просто NIH-говно, изобретённое от скуки (TOML, зла не хватает на этот недоформат).

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от stargrave

+1 за hjson

toml не люблю за уродливый формат для массива объектов

anonymous7
()
Ответ на: комментарий от t184256

Nix

Протекающая абстракция, которая обречена вечно протекать.

Знаешь, что хуже самобытного синтаксиса с закосом под хачкель, полученного путём скрещивания бульдога с носорогом? Только оный самобытный синтаксис с регулярными вставками всех остальных, которые он был призван «заменить».

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от pingvinek

неприятно с LISP

Ох уж этот @vertexua. Покажи на кукле, куда он тебя укусил.

Nervous ★★★★★
()
Ответ на: комментарий от intelfx

Вообще ты прав, но вопрос был, с чем мне приятно работать из существующего =)

t184256 ★★★★★
()

INI (58%)

Да вы что все вместе бахнулись головой???

vertexua ★★★★★
()

Что-то вроде https://jsonnet.org/

Смотря от задачи конечно, но если что-то умеет динамически расширяться - это бывает очень полезно. Я о макрорасширении. Главное чтобы это было не на основе s-expressions

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от t184256

Ну во-первых, он просто уродливый от начала и до конца, но при этом не решает абсолютно никаких новых задач.

Во-вторых, TOML — это по сути INI на стероидах с приклеенной сбоку соплями иерархичностью (сказать, что она «примотана сбоку скотчем», было бы уже слишком щедро). Конструкции «любой скаляр, вложенный в объект» и «объект, вложенный в объект» записываются принципиально разным синтаксисом. То же самое с конструкциями «массив любых скаляров» и «массив объектов» — они принципиально по-разному устроены, их нельзя вкладывать друг в друга. Про массив объектов я вообще молчу — он не воспринимается как массив, эта нотация абсолютно нечитабельна.

Про массивы скаляров, впрочем, тоже молчу. Запись только в строчку, через запятую. It’s JSON/C all over again.

[object]
field = 123
[object.nested]
what = "does this mean"
this = "is unreadable"
[[object.nested.array]]
are = [ "you", "kidding", "me?" ]
[[object.nested.array]]
no = [ "it", "is", "really", "that", "ugly" ]
[object.another]
hierarchy = "fucked"
mental_model = "destroyed"
[[object.screw_you]]
field = [ "how",
"long"
"do",
"you",
"need",
"to",
"find",
"a syntax error?"
]
[object.screw_you.impossible]
where = "is this object?"
intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 5)
Ответ на: комментарий от slovazap

ini подходит для любых случаев, если дополнить его составными именами

struct Config {
    // сначала скаляры и векторы скаляров
    int a;
    std::vector<int> b;
    // потом структуры и векторы структур
    struct Sub1 {
        std::string c;
        std::vector<std::string> d;
    } e;
    struct Sub2 {
        int f;
        std::vector<std::string> g;
    };
    std::vector<Sub2> h;
};

Сериализуется в ini:

a=1
b.1=2
b.2=3
[e]
c=home
d.1=sweet
d.2=home
[h.1]
f=4
g.1=foo
g.2=bar
[h.2]
f=4
g.1=baz
g.2=axe

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

iliyap ★★★★★
()
Последнее исправление: iliyap (всего исправлений: 1)

XML со схемой приятней всего. Всё остальное примерно одинаково. YAML стоит особняком - он хуже всего. Это единственный формат, по которому мне пришлось читать спеку, т.к. интуитивно он не понятен от слова совсем.

Legioner ★★★★★
()
Ответ на: комментарий от iliyap

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

скобок, запятых, отступов, табуляций и прочего говна.

Ну а тут всё говно. Каждая g., каждая точка, каждая квадратная скобка. Только отступами это и можно нормально отформатировать (на самом деле ты это и делаешь, только вместо отступов почему-то используешь родительские ключи), и с возможностью короткие структуры не разбивать на несколько строк (что ini не умеет).

Вот так это должно быть оформлено. Лаконично, наглядно, бзе повторений, без, упаси боже, индексов:

a: 1
b: [2, 3]
e:
  c: home
  d: [sweet, home]
h:
  - f: 4
    g: [foo, bar]
  - f: 4
    g: [baz, axe]

slovazap ★★★★★
()
  • Никаких конфигов, только UI!

  • Для этого должны быть CLI утилиты

Если конфиги надо править руками, с архитектурой что-то не так.

X512 ★★★★★
()
Ответ на: комментарий от X512

Это минусы тебе в карму за нежелание погуглить формат, если тебе действительно интересно.

slovazap ★★★★★
()

Вы о чём ваще и что значат эти каракули в опросе?

petyanamlt ★★★★
()

YAML/JSON для чего-то сложного и вложенного, ini для простого. Голосовал только за YAML, вижу тенденцию к увеличению его количества, как минимум читать его проще остальных.

George
()
Ответ на: комментарий от intelfx

Спасибо, насладился. И все понял.

В XMLе было можно все, кроме прочитать многие тыщи страниц спеков и сохранить разум. Ну и соблюсти эти страницы, конечно же.

В JSON после этой вольницы затянули гайки и стало можно нифига - ни коммента, ни запятой лишней.

В YAML потянули гайку взад и потекла абстракция — anchorы, мерджи и лунатическая типизация на марше.

Стали крутить ещё раз, потуже, сорвали шлицы и получили TOML. И нельзя ничего, и неудобно как-то, и в районе arrays of tables стружка торчит, как погляжу.

Остался один последний маленький рывок в направлении фич и дичи, и будет у индустрии финальный язык разметки, FML. Идеальное тело вращения, не зацепиться, не придраться, идеально расположенный между простотой и навороченностью, никого не задевая. Вертеть его дальше будет нельзя, только что-нибудь на нем.

Переходи на TOML сегодня! TOML — the closest you can get to FML today.

t184256 ★★★★★
()

ini и самописные.

Реестр Windows

Афтар топика юморист.

sparkie ★★★★
()
Ответ на: комментарий от t184256

Какой-то ты странный стал. Похоже, это ваше брно ест мозги, не поеду туда.

Переходи на TOML сегодня

Я уж не знаю, какой вывод надо было сделать из моего поста, но точно не такой.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от mord0d

Вспомнил как недавно пришлось лопатить пятнадцатимегабайтный(!) xml-файл… Брр! Спасибо хоть он был не однострочным, XML позволяет.

А какая разница скольки он строчный? Парсеру пофиг. И 15 MB это копейки. XML дамп OpenStreetMap, например, весит полтора терабайта.

slovazap ★★★★★
()
Ответ на: комментарий от Rootlexx

Если не ошибаюсь, в FreeBSD используется JSON-like формат, но с комментариями

Што? Во FreeBSD много конфигов, от шелла до libucl. Никакого JSON там в помине нет.

slovazap ★★★★★
()

Тех кто изобрёл yaml в аду фурри будут всячески и с фантазией содомировать.

Так же как и тех кто его для конфигурации использует.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от hobbit

Но тогда правильнее говорить не о самих специализированных библиотеках, а о форматах файлов этих библиотек.

Эх, нет отдельного названия этих форматов. Хотя, может быть, стоит исправить пункт голосования на «Форматы файлов специализированных библиотек (libConfuse, libconfig, etc)»? Многословно получается, конечно.

Pravorskyi ★★★
() автор топика
Ответ на: комментарий от AVRS

Может быть. Выглядят примеры вот так:

hobbit, есть ли ещё смысл добавить ссылки прямо в пункт опроса?

... библиотеки (libConfuse, libconfig, etc)
Pravorskyi ★★★
() автор топика

На первое время хочется GUI, но потом текстовые файлы просто удобнее, так как информация в них расположена плотнее и по ним удобнее перемещаться.
Из форматов текстовых файлов видел и полюбил ini и xml.

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от hobbit

Тю… А тридцать гигов не хочешь?

Так это БД, а не конфиг.

torvn77 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.