Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

YAML and Configuration Files

utcc.utoronto.ca

Post reply on HN
Print view View original

31–40 of 96 posts

Re: YAML and Configuration Files

#31

Post by thayne »

simonw wrote: post #3

After resisting it for many years I've finally settled on YAML as my default configuration format. I need a way of expressing the core data types of JSON (key/value mappings aka "objects", arrays, strings, integers, floating points and booleans) - plus comments, and multi-line strings that insulate me from complex escaping rules. YAML does that. It's not perfect, but it's good enough. And in Python I can use yaml.saf…

Why not something like json5 or hjson? They give you the features you listed, but aren't as complex and don't have as many weird edge cases as yaml.

Re: YAML and Configuration Files

#32

Post by Fannon »

YAML (and JSON of course) has the big advantage, that you can use JSON Schema to validate it and to provide realtime code intelligence in many Editors (VScode, IntelliJ, Monaco Editor in the web, many Web IDEs. Allthough you might need a plugin for YAML, where JSON works out of the box).

So it's easy to hate on the feature overload of YAML or on the lack of features of JSON, but it's hard to throw out the rich ecosystem along with them they already have established.

One format I personally like is JSON5 (https://json5.org/) as it's very much just JSON, but with some more modern JavaScript (ES5) syntax allowed, including comments. Looks like a parser / serializer for it is also still rather consise.

Although, I'm always wondering which features of YAML to best not use / touch. My personal approach would have been to leave some advanced features to optional pre-processors or real programming / template languages.

Re: YAML and Configuration Files

#33

Post by amirkdv »

thayne wrote: post #25

> YAML isn't a configuration language or a configuration language format, it's a serialization format I think YAML is even worse as a serialization format than a configuration format. It has too many ambiguities, implementations are too inconsistent, and many implementations are insecure by default with untrusted input. > Using a good custom designed configuration file format instead of trying to shove things through…

> I think YAML is even worse as a serialization format than a configuration format.

This. I find YAML to be the least offensive option for configuration and one of the worst for serialization.

I might be misinformed, but I find it absurd that in 2021 we still don't have a default, universally available tool that supports the basic table stakes without headache:

1. core data types (number, string, etc)

2. lists, maps, and arbitrary nesting

3. comments

4. multiline strings

5. is acceptably readable

6. Just Works everywhere

YAML does get 1-5 right (specifically 3 and 4 that JSON doesn't and IMO better in 5). But then it adds a ton of complexity that has left us without a standard, safe, and sane parser implementation: anchors and references (& and *) , casting (via !!), custom data types (via !), loads of other things I don't understand.

Re: YAML and Configuration Files

#34

Post by janjones »

Complex configurations should simply use configuration programming languages like Lua. They can start as simple as JSON/YAML but stay flexible as the complexity grows thanks to functions, references, etc. Parsing them should be also easy (configuration languages are meant to be embedded in others, just like JSON/YAML).

Re: YAML and Configuration Files

#35

Post by thayne »

oweiler wrote: post #21
seized wrote: post #20

A while back it took myself, a data center engineer, and two engineers from the appliance vendor a solid 20 minutes to figure out the problems with a ~12 line yaml file that needed two or three lines added (network config file). Between syntax, indentation, etc it required a few tries. Plus there was a copy and paste in there via SSH. I don't know what a better alternative is but yaml can be incredibly frustrating.

The problems you describe wouldn't exist when using XML with a schema.

Maybe, but XML has a whole host of other problems.

Re: YAML and Configuration Files

#36

Post by thayne »

Vitamin_Sushi wrote: post #2

The solution for defining a more complicated config is to write your own config file format? I would think a custom format wouldn't necessarily be easier for others to read and write unless it came with a guide/readme, but then that's just one more thing to learn. Admittedly, I've never had to write a super complicated config file, but can anyone tell me why I shouldn't continue to use something like JSON for all of…

Two big reasons you shouldn't use json for config: comments and multi-line strings. json supports neither, although there are many other simple formats that do.

Re: YAML and Configuration Files

#37

Post by thayne »

simonw wrote: post #5
beached_whale wrote: post #4

Earlier quoted context omitted.

Let’s not forget that almost every JSON parser optionally supports comments and trailing commma’s when parsing.

Which ones do that? I've not encountered many myself.

Ruby's supports comments. But that's the only one I know of

Re: YAML and Configuration Files

#38

Post by brundolf »

amirkdv wrote: post #33
thayne wrote: post #25

> YAML isn't a configuration language or a configuration language format, it's a serialization format I think YAML is even worse as a serialization format than a configuration format. It has too many ambiguities, implementations are too inconsistent, and many implementations are insecure by default with untrusted input. > Using a good custom designed configuration file format instead of trying to shove things through…

> I think YAML is even worse as a serialization format than a configuration format. This. I find YAML to be the least offensive option for configuration and one of the worst for serialization. I might be misinformed, but I find it absurd that in 2021 we still don't have a default, universally available tool that supports the basic table stakes without headache: 1. core data types (number, string, etc) 2. lists, maps,…

It's a real shame JSON doesn't have 3 and 4, because it would be so easy and it's otherwise pretty much perfect imo. No ambiguity, every value type can be identified by its first character, clean and reasonably minimal syntax.

Re: YAML and Configuration Files

#39

Post by amirkdv »

meowface wrote: post #23
simonw wrote: post #3

After resisting it for many years I've finally settled on YAML as my default configuration format. I need a way of expressing the core data types of JSON (key/value mappings aka "objects", arrays, strings, integers, floating points and booleans) - plus comments, and multi-line strings that insulate me from complex escaping rules. YAML does that. It's not perfect, but it's good enough. And in Python I can use yaml.saf…

YAML seems to be one of the most polarizing things in the software industry. I'm personally a big fan of it, though I agree with the author that it becomes a pain once you start trying to use it like a DSL or templating language. I use it in pretty much every project, but I've worked with people who've said they hate it with a burning passion. And it's kind of a trope to see anti-YAML manifestos on HN and /r/programm…

> it becomes a pain once you start trying to use it like a DSL or templating language.

I like YAML and use it a lot. But I'd argue the fact that it even allows/encourages you to do such things with it is a design flaw that ultimately has kept it from Do One Thing Well.

Re: YAML and Configuration Files

#40

Post by sofixa »

amirkdv wrote: post #33
thayne wrote: post #25

> YAML isn't a configuration language or a configuration language format, it's a serialization format I think YAML is even worse as a serialization format than a configuration format. It has too many ambiguities, implementations are too inconsistent, and many implementations are insecure by default with untrusted input. > Using a good custom designed configuration file format instead of trying to shove things through…

> I think YAML is even worse as a serialization format than a configuration format. This. I find YAML to be the least offensive option for configuration and one of the worst for serialization. I might be misinformed, but I find it absurd that in 2021 we still don't have a default, universally available tool that supports the basic table stakes without headache: 1. core data types (number, string, etc) 2. lists, maps,…

HCL does all of those.

TOML is pretty close as well.

Post reply on HN