про гуи говорили

ты можешь сгенерить ему каркас, в началае, но потом не смей его трогать

где тут про гуй?

да при чем тут? не надо поганить что пользователь написал, хочешь заперсистить в ФС, делай как хочешь, но не туда, где пользователь редактирует

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

Про гуй далеко выше.

возвращаемся к моим словам о хранении конфигурации и интерфейсе для пользователя

еще выще было, про то что конфиг и есть интерфейс, я об этом

Ну хорошо.

Значит, я не об этом.

Тогда хочу просто сказать, что автосгенеренные json, ini – адекватно, yaml – ад.

Первые можно отдать на модификацию, yaml – можно выкинуть.

Тогда хочу просто сказать, что автосгенеренные json, ini – адекватно, yaml – ад.

да нет же, автосгенеренный срать как выглядят

их не надо пользователю показывать

Пример?

пример чего?

сгенеренный автоматом json/yaml always bad?

Пример ужасного невозможного невложенного json-конфига.

есть конфиг, ты его читаешь, и есть файлиг settings, который ты генеришь и все равно в каком он формате

сгенеренный автоматом json/yaml always bad?

Yaml – не всегда, но иногда генерятся всякие именованные сущности и прочая радость, которую редактировать действительно неудобно: хочется подправить одно значение, приходится править много строчек.

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

формат сериализации не является интерфейсом взаимодействия с пользователем

Не понимаю, какой я из этого должен сделать вывод. Я говорил о редактировании сгенерированного конфига. Ситуация не частая, но штатная. Куда персистить, что персистить? ?

сгенеренный конфиг - эт оуже не конфиг, а сериализованные данные приложения

а редактирвоать надо конфиг

Сгенеренный конфиг – это внезапно сгенеренный конфиг.

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

$ ls -1 super_puper_bin super_puper_bin.conf .super_puper_bin.db

вот так это надо воспринимать

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

а, ну, тогда конечно. тогда мы не про велосипеды же;)

даже не, пусть он будет сгенерен чем угодно

Я рад, что вы пользуетесь идеальным софтом и/или пишете все свои тулзы с нуля и правильно.

Мне доставался и другого рода софт, с которым приходилось работать.

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

И я имел опыт со свежими и сгенеренными конфигами ini, json, yaml. Первые боль, вторые правились быстрее всего, третьи ад.

Я рад, что вы пользуетесь идеальным софтом и/или пишете все свои тулзы с нуля и правильно.

я пользуюсь немерянным стеком, нигде не т конфигов на json, слава богу, повезло

А мне повезло, что я им не пользуюсь. :)

И я имел опыт со свежими и сгенеренными конфигами ini, json, yaml. Первые боль, вторые правились быстрее всего, третьи ад.

кто и зачем из генерил. я вот никак не могу понять

Была немного странная система деплоя, написанная и активно продвигаемая внутри компании. Она мне не нравилась, но это была "политика партии".

А у нас конфиги ваще на питоне. Валидируются по схеме.

Никаких проблем никто не испытывал.

Также частью политики было развернуть этой системой готовые сервисы, которые были совершенно не готовы к интеграции.

Была немного странная система деплоя, написанная и активно продвигаемая внутри компании. Она мне не нравилась, но это была "политика партии".

и кто теперь про велосипеды;)

Кстати, конфиги на питоне – неплохая тема.

в любом место можно придумать боль. это не проблема формата, а проблема его применения.

и кто теперь про велосипеды;)

Я про велосипеды. Я не хочу делать велосипед для чтения конфига.

Велосипедов, внезапно, может быть много.

И мне хочется на один меньше.

Поэтому, я и говорю – если весь ваш софт идеален, я рад. У меня такого в жизни не было.

(Ну разумеется, кроме петпроджектов, в которых, конечно же, я писал самый прекрасный код в истории человечества.)

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

Ну он им и остался. Я лишь сказал, что на практике оказывается болью.

Вы думаете, что надо ini/yaml/whatever. Кто-то тоже думал.

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

Когда вы говорите, что json никогда не должен использоваться для конфигов, то в реальной жизни софт авторов, считающих так же, оказывается болью.

И всегда хотелось этих авторов спросить, что ими двигало.

И надеюсь не "json для транспорта".

Вот я тут https://telegram.me/spblug пользователям закинул про конфиги. Говорят, yaml

Еще здорово, когда фреймворк поддерживает несколько вариантов конфига. Ну, например, json, yaml и xml. В некоторых ситуациях один из вариантов может быть более удачным чем остальные.

Мне уже надоело. ) Как разработчик/инженер я буду работать с чем угодно. И я даже не буду хотеть сильно ругаться, если кто-то другой случайно стал причинять другим боль ("мы планировали развивать проект три месяца, а ему три года, 100500 sloc и деплой на кластер"). Но я никогда не пойму субъективных предубеждений на старте.

а разве на старте в местах, где нет явных требований, бывает что-то кроме субъективности?

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

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

Так требования всегда какие-то есть, и они почти всегда неполные. Дело в другом: бывают разные аргументы в выборе. "Конфиги должны быть такими, чтобы они могли реактироваться моим любимым sed'ом" – не очень хорошая причина. "Мы думаем, что нам не понадобится хранить в конфиге список" – получше.

ну да, всё так

поэтому @pragus вернись и выставь требования

Скоро ITGM #7. Ищем докладчиков! https://plus.google.com/+SergeMatveenko/posts/DdUa7bfkph8

Разговор начался с позиции "ненавижу тех, кто делает json-конфиги" и "json никогда не должен использоваться для конфигов". Это тупо предубеждения, ибо речь идет ни о каком-то конкретном проекте, а вообще.

я остался при своем

Да здесь все, очевидно, остались при своем.

Но это даже немного хорошо. Обычно в таких случаях я просто понимаю, что не ограничиваю себя заранее в возможностях, и это мне на руку.

http://www.meetup.com/spbpython/events/229603774/

https://github.com/vstakhov/libucl

мне нравится

а ты уже использовал?

нет ещё, но думаю. уж очень синтаксис удобный

да, и @eigenein одобряе, наверное;)

Выглядит вполне торжественно.

выше ссылку скидывал на https://github.com/hashicorp/hcl, это производное от libucl, на go

ну только надо бы им собраться и перестать называть это двумя языками ucl и hcl, а сделать один xCL, который они будут в своих либах реализовывать

https://github.com/typesafehub/config/blob/master/HOCON.md

ну только надо бы им собраться и перестать называть это двумя языками ucl и hcl, а сделать один xCL, который они будут в своих либах реализовывать

тогда есть надежда затащить это в RFC

для питона: https://github.com/chimpler/pyhocon

посмотрел, некоторые вещи в HOCON заставляют меня представлять в качестве целевой аудитории этого хищников, а в качестве авторов - чужих

https://github.com/typesafehub/config/blob/master/HOCON.md

где-то на середине страницы захотелось взять огнемет и пойти сжигать кладку авторов

toml еще вроде бы не упоминали https://github.com/toml-lang/toml#comparison-with-other-formats

О, микс ini и json'а. )

Я писал про TOML. Первый раз стокнулся с ним в hugo

Это дичь )

чем плох?

ну, кстати https://github.com/toml-lang/toml#example такой пофикшенный ini

https://github.com/peteut/circbuf/blob/master/circbuf/__init__.py#L113

а это так принято?

Веселый код. Binary tricks, все дела, но мне ничего не понятно, что происходит. )

Эта битовая магия - тоже самое что "mod size"

Эта битовая магия - тоже самое что "mod size"

а где там битовая магия?

Перевожу один модуль с java на питон, где активно используются сдвиги влево. Как перевести их на питон?

блин