Comments 34
YAML спроектирован настолько человекопонятным, что его человекопонятностью рекомендуют не пользоваться, чтобы не было путаницы. А то и вообще предлагают генерировать его из JSON.
Придерживайтесь best practices
Всегда заключайте строковые значения в кавычки.
Что-то ни одного строкового значения в кавычках в примерах в тексте статьи не заметно.
ну почему, есть парочка-троечка :)
user: 'root' pass: 'passwd' db: 'appdb'
Не, там есть в разделе "Генерируйте YAML из кода" строковые значения в кавычках, только оно скармливается этому самому генератору, и он уже выдаёт без кавычек :)
автор предлагает использовать линтеры, например yamllint, но по-умолчанию большинство из них предпочитают задание строковых параметров без кавычек, выплевывая варнинги о String value is redundantly quoted. Конечно это можно обойти, настроив параметры quoted-strings: extra-allowed, extra-required, required в конфиге линтера, но зачем?
Не стоит выдумывать избыточности и по моему опыту заключать в кавычки нужно только действительно необходимые строки, например, 'true', если явно не ожидается конвертации в булево значение или строки со слешами, в случае путей Windows из-за возможных ошибок со стороны софта, при обработке сконвертированного yaml в json из-за особенностей экранирования.
В противном случае нужно писать внутренние стайлгайды, объясняя, что если в строке есть слово с верхним апострофом, то его нужно заменить на " или же такую строку нужно оборачивать уже не в одинарные кавычки, а в двойные, чтобы не нарушать орфографию написания или делать из in-line multiline или убирать апостроф вообще :)
Лично я написал просто набор правил для линтера на основе параметров выше, которые заставляют явно использовать кавычки только на определенных строках, которые учитывают основные нюансы конвертации из yaml в объект или json, конфигурация поставляется как дефолтная во всех репах и если у сотрудника настроен линтер и форматер, то это укажет на ошибку и поддерживать стайл-гайды и создавать дополнительную когнитивную нагрузку и усложнять список того, что нужно знать при онбординге не придется.
Мало того. Yamlfmt эти кавычки с явно строковых значений снимет
Параметры подключения к БД используются также в конфигах других сервисов. Выносим их в отдельный файл
mysql-creds.ymlТеперь подключаем в основном конфиге через якорь
*
Спецификация yaml не поддерживает включения из других файлов
Все бы хорошо, но даже визуально в структуре данных на json больше символов, а потом ее еще и конвертить надо. Оч спорно.
А вот за kue спасибо.
Ох уж эти синонимы для true/false. В конфигах Home Assistant очень часто используются строковые литералы "on" и "off". Забыл кавычки - не работает. Ну это и к слову о том, что кавычки лучше использовать явно.
Отличная статья! YAML-файлы могут быть запутанными, но благодаря этому сборнику советов я смог значительно упростить свою работу с ними. Рекомендую всем, кто сталкивается с YAML в своей работе.
Первый и единственный комментарий данного пользователя. Более того, это вообще единственный случай активности данного пользователя. Примечательно, что восхищался пользователь при этом не добавил "отличную" статью в свои закладки. Интересная шляпа.
Кто-то ботов тестирует.
Эм, ну то есть по вашему на Хабре все должны ворчать как все плохо? Или человек не может чем-то восхищаться? Или ему не должна эта статья понравится? Не понимаю вашей претензии и мнительности. У меня вот этот тоже первый комментарий, я тоже бот по вашему? Ну и если это тестирование ботов, то где все остальные? Да и в конце-концов, зачем вы за другими пользователями следите, как-то подозрительно, не находите? Следите за своей активностью.
В примере генерации YAML из Питона не понял чем код на Питоне лучше. На YAML короче, и на YAML то же можно записать несколько параметров в одну строку если есть такое желание.
Правило номер 1 - не используйте yaml ?
А что использовать? JSON очень ограничен в выразительности и избыточно строг. XML совершенно не пригоден для сопровождения человеками - исключительно машинный формат. Всякие прочие форматы конфигов слишком разнообразны и довольно бедны в возможностях создания иерархий объектов, списков, словарей.
"Генерируйте YAML из кода". Если перефразировать, получится: "Не пользуйтесь YAML". На этом можно было статью и закончить. )
YAML Designer. Онлайн-редактор для общих конфигураций YAML с компонентами пользовательского интерфейса.
Просто из интереса, про какой инструмент идет речь? Он точно существует? Ничего с подобным названием не гуглится, кроме каких-то проприетарных DevOps-инструментов Azure:
Hidden text
В текст закралась ошибка, автор имел в виду вот этот редактор: https://codebeautify.org/yaml-editor-online Спасибо за вашу внимательность!)
Ручное написание сложных вложенных конфигураций на YAML задача не из приятных. Гораздо проще сначала определить нужную структуру данных в виде словарей и массивов в том же Python,а затем сгенерировать из нее YAML с помощью соответствующей библиотеки.
И чем оно "гораздо проще"? YAML и читать легче, и писать легче. А предлагается зачем-то продублировать его в коде в более замороченном формате, и потом вместо одной сущности - собственно, YAML-файла - хранить две: YAML-файл и код для его генерации, с идентичными данными, только в другом формате. Чо тогда вообще не забить на YAML и не хранить данные в питоновском модуле, а вместо чтения делать импорт?
Сборник советов, как упростить работу с YAML-файлами