Earlier quoted context omitted.
Sort of, I deliver a GUI that exports into YAML for pretty much only reading, portability, and version control. People are expected to do the editing in the GUI, only using YAML for editing when doing complex regex operations that my GUI doesn't support.
If people aren't editing it by hand, why does the format matter? Why not just use JSON? Tools for too-complex-for-the-GUI manipulations are at least as good for JSON as they are for YAML, and the editing is less error-prone.
YAML: Probably not so great after all
201–210 of 457 posts
Re: YAML: Probably not so great after all
#202I've used YAML as the format for a config file, and I certainly regret that choice. Trying to explain to someone that doesn't know YAML how to edit it without setting them up for failure is quite annoying. There are too many non-obvious ways to screw up, like forgetting the space after the colon or of course bad indentation.
I've never had someone that needed extensive help understanding YAML and that's besides reviewing work for people just coming up to speed. Find me an IDE or editor that doesn't have YAML support. Also, YAML supports comments so if you have pitfalls people need to know about you can document them inline.
Your argument is people who don't know things might screw stuff up. Well Yeah! This applies to everything.
Re: YAML: Probably not so great after all
#203Kubernetes supports JSON but overwhelmingly leans towards YAML. I've had to spend some time really grokking it to do basic dev ops, and now have my IDE pretty dialed to support it. That said, its not my favorite by a long shot. Can Jsonette save us?
Re: YAML: Probably not so great after all
#204Earlier quoted context omitted.
I say just use JSON. Everyone knows it already and it's good enough. Use a parser in your app that allows comments and trailing commas like vscode does.
That's not JSON anymore, that's some custom format that's JSON inspired.
(No, not YAML.)
Re: YAML: Probably not so great after all
#205fish shell is looking for a new text serialization format for its history file (currently it uses an ad-hoc broken psuedo-YAML). Boxes to check: 1. Self describing format 2. SAX-style parser available to C++ 3. Easy for users to understand and ad-hoc parse using command-line tools 4. No document closing necessary, so appending is trivial YAML looks pretty good: - cmd: git checkout file.txt when: 1565133286 pwd: /home…
Re: YAML: Probably not so great after all
#206From my experience, while YAML itself is something one can learn to live with, the true horror starts when people start using text template engines to generate YAML. Like it's done in Helm charts, for example, https://github.com/helm/charts/blob/master/stable/grafana/te... Aren't these "indent" filters beautiful?
Surely using an encoder on an object/structure hierarchy (like people do with encoding/json) is the way to go?
On the other hand, the quality of the yaml libraries in Go wasn't great, last time I had to choose a configuration file format.
Re: YAML: Probably not so great after all
#207Re: YAML: Probably not so great after all
#208I strongly recommend doing away with config files completely for sake of ease of use, maintainability and security. Instead just declare all config variables within code itself in a separate config class/module file, along with initialization to default values and provides dynamic getter/setter interface over a debug API (which can be enabled/disabled via a command line flag). If you want, you can also provide a frie…
Re: YAML: Probably not so great after all
#209From my experience, while YAML itself is something one can learn to live with, the true horror starts when people start using text template engines to generate YAML. Like it's done in Helm charts, for example, https://github.com/helm/charts/blob/master/stable/grafana/te... Aren't these "indent" filters beautiful?
Why would they have chosen to use template/text to generate YAML? That seems insane. Surely using an encoder on an object/structure hierarchy (like people do with encoding/json) is the way to go? On the other hand, the quality of the yaml libraries in Go wasn't great, last time I had to choose a configuration file format.
Re: YAML: Probably not so great after all
#210 * YAML can have several 'documents' in the same file,separated by ---
* there are anchors and references
* easy to read multi line texts
* it's also a superset of JSON
I can see, how choosing YAML when you just wanted readable JSON might give you more headaches than expected.And like someone else said, putting another template engine (or two) on top of YAML is when the real problems start.