Связь?
чтобы удалить что-то, нужно w в его каталоге
На уровень выше? Да ладно
потому что удаление c = изменение списка файлов в b
А файла? )
а какая разница?
Ок, т.е. если я не обладаю w правом на директорию я не могу в ней ничего удалить
Это ... Хм
Звучит странно, но обхясняет почему не работает rm -rf . По крайней мере почему он далеко не зайдет объяняет
$ mkdir a $ touch a/b $ chmod -w a $ rm a/b rm: cannot remove ‘a/b’: Permission denied
unexpected
более того
$ chmod +w a
$ chmod -w a/b
$ rm a/b
rm: remove write-protected regular empty file ‘a/b’? y
$ ls a/b
ls: cannot access a/b: No such file or directory
Но действительно так )
там в линуксовой рассылке в файликах лежит pdf-ка руководство системного администратора, весьма рекомендую;)
всем привет! :)
вот интересно, это товарищи осмысленно пришли или RBTB...
да
это библия
Привет. ) Я живой и осмысленный. )
Что не так с конфигами на json?
Кстати, есть ещё протобаф, если хочется валидацию
Протобаф для конфигов?..
Что не так с конфигами на json?
Надо не путать хранилище настроек и конфиг. Конфиг - это одновременно хранилище настроек и интерфейс для их редактирования. Так вот, строгие форматы хороши для первого и плохи для второго.
Меня сейчас, наверное, закидают камнями, но все выглядит как острая нехватка опыта использования ini-файлов, начиная парсингом числовых значений и списков адресов вручную. Если у вас конфиг в json, то вы просто в меру ленивы, чтобы не писать велосипед. И пока формат отлично парсится и легко редактируется человеком (кто-нибудь испытывает сложности?) - не вижу никаких проблем. И мне кажется, что позиция вида "json это транспорт" резко ограничивает свои собственные способности.
Ну протобаф совершенно нечеловекочитаем, с ним вопросов нет. )
Меня сейчас, наверное, закидают камнями, но все выглядит как острая нехватка опыта использования ini-файлов, начиная парсингом числовых значений и списков адресов вручную. Если у вас конфиг в json, то вы просто в меру ленивы, чтобы не писать велосипед. И пока формат отлично парсится и легко редактируется человеком (кто-нибудь испытывает сложности?) - не вижу никаких проблем. И мне кажется, что позиция вида "json это транспорт" резко ограничивает свои собственные способности.
Не легко он редактируется. Проверено на кошках
Попробуй написать список из объектов, внутри которых иногда бывают списки и объекты руками
Обязательные кавычки, жесткий формат булов, жесткие требования к запятым.
Иногда, неожиданное восприятие форматов
А еще попробуй его валидировать
Схему еще ладно, может типы. А вот дефолты прописать? А их как раз умеет ConfigParser, потому что его для этого писали
Ну и еще попробуйте переносить куски конфига на json, особенно, если трогаете последние значения или выделяете кусок в отдельный конфиг
Доводить конфиги до такого уровня вложенности - что-то странное вне зависимости от формата, в котором его хранить. И все наши выборки кошек заведомо нерепрезентативны. Когда появляется необходимость задать что-то чуть-чуть проще ароматного значения, начинаются вопросы "а как же это в конфиге хранится".
*атомарного
Доводить конфиги до такого уровня вложенности - что-то странное вне зависимости от формата, в котором его хранить. И все наши выборки кошек заведомо нерепрезентативны. Когда появляется необходимость задать что-то чуть-чуть проще ароматного значения, начинаются вопросы "а как же это в конфиге хранится".
Так как удобно хранится:) в смысле интуитивно
Чаще всего - так, как задумал разработчик. )
Блин, ну попробуйте пожить с конфигом на json с несколькими параллельными инсталляциями и сборкой конфигов из кусочков ансиблом
Чаще всего - так, как задумал разработчик. )
Нет, так как спеке ini формата написано
Там вариантов не один и все работают одновременно и все интуитивные, их можно просто писать, скорее всего угадаешь
Нет, так как спеке ini формата написано
Спека очень бедная. Она умеет только примитивные значения.
Из ConfigParser прилетает тупо строчка. Как ее распарсил разработчик - загадка.
Обязательные кавычки, жесткий формат булов, жесткие требования к запятым.
Просто vim + any linter.
Блин, ну попробуйте пожить с конфигом на json с несколькими параллельными инсталляциями и сборкой конфигов из кусочков ансиблом
И снова моя оговорка, что сложность конфигов и формат - таки разные вещи. ) Можно сделать плоский json конфиг.
Так я и начал с объяснения, зачем. :)
В yaml vs toml можно так же накосячить. Вопросы типа dict vs list.
Поэтому не вижу смысла кидать особый камень в сторону json
вот я решаю до фига devops задач каждый день, я вам точно скажу, что с json-конфигами гемор шо пипец. если вам не хватает ini, используйте yaml, пожалуйста, и пусть будет зависимость
Поэтому не вижу смысла кидать особый камень в сторону json
дай его людям и тебя закидают камнями
Дима, не надо
Тебя точно так же закидают за yaml
Yaml - надмножество Json. Поэтому, позиция не совсем понятна
ну, вот, по опыту, люди и автоматичка лучше живут с xml, чем с json, серьезно
И снова. Ни один формат не обязывает использовать его так, чтобы убивать.
Мне непонятен этот опыт. По-моему запутатьсяво вложенностях xml гораздо проще
А в yaml спутать лист и дикт. Как пример docker-compose
У вас есть инструменты - используйте их разумно, не впадая в крайности. И если говорить о собственном опыте, то я наелся ini-файлов.
ini через ConfigParser неудобно редактировать. list(inventory['uk_kvm'].keys())[-1]
Вот это мне неудобно
Yaml - надмножество Json. Поэтому, позиция не совсем понятна
а ты забудь об этом и сравни их глазами человека, которому их сапортить надо
ini через ConfigParser неудобно редактировать. list(inventory['uk_kvm'].keys())[-1]
а его надо руками редактировать, если ты используешь автоматическое хранилище, то его можно сделать отдельно, кроссплатворменными средствами
Саппортил. Yaml - ад. Ini - преисподняя.
Зачем? Я просто буду использовать yaml/json.
есть какая-то фигня, которая использует реестр и xdg dirs на винде/линухе соотвественно
это хранилище средствами ос, которое поддерживает системный и пользовательские конфиги, что правильно
а ini - это способ записать параметры запуска. т.е. некий боле удобный способ, чем писать в коммандной строке
а всякие json/yaml вы можете использовать как вам нравится, но это будет тоже, что использовать для этого sqlite или mongo или любое персистанс хранилище
Саппортил. Yaml - ад. Ini - преисподняя.
да? а ты пробовал json через tee или sed при деплое редактировать?;)
тот же ансибл умеет дополнить ini нужным значением, это просто и удобно, json пересоздавать надо и перевалидировать
ну и ini - это еще и ограничение. если ты можешь его написать руками - значит пока у тебя всё хорошо
а всякие json/yaml вы можете использовать как вам нравится, но это будет тоже, что использовать для этого sqlite или mongo или любое персистанс хранилище
Разные интерфейсы редактирования человеком. Не то же самое.
вот, например, монго - был ini, стало много значений, стал yaml, потому что это как бы иерархический ini
да? а ты пробовал json через tee или sed при деплое редактировать?;)
Я привык не усложнять себе жизнь редактированием через sed.
и я согласен, любой формат можно использовать не по назначению и/или превратить его в кошмар;)
Я привык не усложнять себе жизнь редактированием через sed.
ты удивишься;)
Ты привык извращаться? )
Разные интерфейсы редактирования человеком. Не то же самое.
так ini для редактирования человеком, в том то и дело
Ты привык извращаться? )
я привык использовать инструменты по назначению
Ага. Тогда, наверное, понимаешь, что извращаться sed'ом это не совсем по назначению.
я вот только вчера сделал коммит sed-ом в мой рабочий проект за минуту. уверен, любое ide с его gui потребовалы больше времени
так ini для редактирования человеком, в том то и дело
Мне, как человеку, хотелось плакать, конфигурируя что-то в ini. :)
это при том, что я код редактирую только в ide, без всяких ущербных редакторов
Мне, как человеку, хотелось плакать, конфигурируя что-то в ini. :)
ну тут надо разбираться что такое "что-то"
Пример с головы:
[blabla]
admins = vasya

А второй админ через запятую? Через пробел? Другой разделитель? А если я не угадаю, то моего админа будут звать "vasya,petya".
Используйте ущербные редакторы, они полезны и позволяют экономить время. )
Пример с головы:
[blabla]
admins = vasya

А второй админ через запятую? Через пробел? Другой разделитель? А если я не угадаю, то моего админа будут звать "vasya,petya".
можешь и через пробел и через запятую, такой ini но это мелкая проблема формата, которая понятна и этому легко убучается даже девочка "убейти меня я дура", но вот json-у ее научить невозможно
надо смотреть со стороны пользователя, а не человека, который знает что такое bnf
Не, не могу. Потому что разработчик впилил value.split(" ").
Не, не могу. Потому что разработчик впилил value.split(" ").
чо то мы разными configparser пользовались, похоже
да, видимо я сам хачил;)
ну, значит не надо использовать ini уже для списков;)
но вот
{
"blabla": {
"admins": ["vasya"]
}
}

это перебор, имхо
А что оптимально?
При условии, что я как пользователь хочу точно знать, как не ошибиться.
Но можно для начала и без этого условия. )
При условии, что я как пользователь хочу точно знать, как не ошибиться.
гуй, опция Preferences
Ну это уже нечестное ведение диалога. )
а если файлик, то дока и ini на пять строк. обычно достаточно
это для пользователя
чтобы не ошибиться в програмно легко читаемом формате, нужен валидатор, а это отдельная программа, которой в общем случае у пользователя нет
Где "там"?
ну т.е. достаточно один раз это юзеру сказать
а вот тебе это и сказали, в доке
:)
Еще раз: ini фиксирует формат только примитивных значений. Все остальное – полет фантазии разработчика. И прелесть вашего любимого ini в том, что любую ошибку он тихо схавает.
ну да, а ты напишешь после валидации значений, у меня такого нет
а yaml – надмножество json, и я уже могу сказать, что вы предвзяты к json )
Еще раз: ini фиксирует формат только примитивных значений. Все остальное – полет фантазии разработчика. И прелесть вашего любимого ini в том, что любую ошибку он тихо схавает.
ошибку синтаксиса. ошибка синтаксиса - далеко не любая. по опыту, главные ошибки юзеров не в синтаксисе:)
Я о том же.
а yaml – надмножество json, и я уже могу сказать, что вы предвзяты к json )
да по фигу кто чье множество. суть в том, что yaml руками редактирвоать проще
Любые ошибки после = в ini съедаются и обнаруживаются очень поздно.
Любые ошибки после = в ini съедаются и обнаруживаются очень поздно.
в данном случае, я не понимаю что такое поздно.
да по фигу кто чье множество. суть в том, что yaml руками редактирвоать проще
Именованные сущности в yaml – тоже нормально? )
юзер стори: 1. написать конфиг 2. запустить программу 3. получить сообщение от программы что не так в конфиге
тут нету поздно или рано, оно одновременно
для пользователя
в данном случае, я не понимаю что такое поздно.
Поздно, это когда все развернул и увидел, что оно не работает правильно из-за своего кривого значения.
Именованные сущности в yaml – тоже нормально? )
не понимаю по-русски
Поздно, это когда все развернул и увидел, что оно не работает правильно из-за своего кривого значения.
см. юзерстори
не понимаю по-русски
Сказано, что yaml редактировать проще. Отвечаю: yaml сложнее по определению.
прелесть ini в том, что ты можешь юзеру точно сказать почему что-то не так, в терминах бизнес логики
см. юзерстори
Смотрю. Валидация не словит мою ошибку в разделителе.
И она вообще ничего не словит, ибо все значения в ini – строки.
Сказано, что yaml редактировать проще. Отвечаю: yaml сложнее по определению.
не надо передергивать. yaml сложнее в смысле позволяет больше. и как раз благодаря этому его проще творить. он позволяет делать вид удобным для редактирвоания
Смотрю. Валидация не словит мою ошибку в разделителе.
значит ты ее плохо написал
А я вообще писать уже написанное кем-то другим мало люблю. _
ты валидируешь ini сам, в терминах логики приложения. еще раз. ini - это просто удобные параметры командной строки
не надо передергивать. yaml сложнее в смысле позволяет больше. и как раз благодаря этому его проще творить. он позволяет делать вид удобным для редактирвоания
Я не передергиваю, я видел yaml конфиги.
А я вообще писать уже написанное кем-то другим мало люблю. _
никто не писал логику твоего приложения до тебя
Логику парсинга списков, приведения типов, whatever уже написали за меня авторы модуля json. Мне осталось проверить лишь бизнес-логику, а корректность описания вот этих вот строчек в ini.
*а не
людей ни то, ни другое не устраивает полностью
еще один вариант https://github.com/hashicorp/hcl (с описанием мотивации)
Конечно, если вам нравится снова и снова парсить все это – ваше право, если вам не запрещают. Но тогда: предусматривайте все возможные косяки в значениях и обучайте всех остальных любителей ini-файлов делать так же, чтобы люди не бились головой.
еще раз, не хватает ini - не используй
Мне жалко времени на велосипедостроение.
да, списки уже перебор
ноиногда лучше сделать сплит, чем мучить обезьянок json-ом
Так речь-то была о чем? Посмотрите выше, там было что-то про вложенные конфиги и что в ini конфигурить было бы лучше.
не, там про yaml :)
Без нарушения общности. )
ну и то что json для этого неудобен
просто вот он неудобен
хер с нми с ini
но json - это не формат для конфигов
он для этого не подходит.
.
:)
Это таки предубеждение. Если уже речь о том пошла – то плохо все.
да, возможно:)
жизнь говно, так то
Yaml выносит мозг из-за очень похожих спецсимволов в разных конструкциях, а если он автосгенерирован, то в нем появляются все его прелести, от которых плакать хочется даже больше, чем от ini. )
Короче, все отстой, давайтн сделаем свой стандарт. :)
Yaml выносит мозг из-за очень похожих спецсимволов в разных конструкциях, а если он автосгенерирован, то в нем появляются все его прелести, от которых плакать хочется даже больше, чем от ini. )
вот, автосгенерированный конфиг - это срань в любом случае.
возвращаемся к моим словам о хранении конфигурации и интерфейсе для пользователя
Ну не скажи. json.dumps(..., indent=2) или ConfigParser.save(...) еще вменяемы.
Чего не скажешь о том, что делает PyYAML.
я не пробовал.
но вот знаю, что форматтер в Eclipse меня устраивает
у меня весь ansible проект им отформатирован
я тут программирую на yaml просто;)
Не, интерфейс, конечно, это хорошо. Если сервис уже знает, куда коннектиться, чтобы хранить настройки.
Не, интерфейс, конечно, это хорошо. Если сервис уже знает, куда коннектиться, чтобы хранить настройки.
да при чем тут? не надо поганить что пользователь написал, хочешь заперсистить в ФС, делай как хочешь, но не туда, где пользователь редактирует
Это намек, что интерфейса без конфига может вообще не быть.
Сервис просто не запуститься, так скажем.
*запустится
конфиг и есть интерфейс, внезапно
это интерфейс взаимодействия с пользователем