Live data from Hacker News

YAML and Configuration Files

utcc.utoronto.ca

61–70 of 96 posts

Re: YAML and Configuration Files

#61

I find YAML an incredibly difficult configuration format to write by hand for anything but the simplest of files. Agree it’s a sterilisation format and not a great one. Likewise for JSON. No one can say setting up a webpack config is simple which uses JSON. It’s a recent trend. I hate working with the Kubernetes ecosystem as it’s lines of YAML config. At the same time I love working with OpenBSD / Linux. OpenBSD espe…

Specifically, neither YAML nor JSON are configuration formats (despite everyone's desire to use them as such).

TOML is a very good generalization of a simple, straightforward configuration file format which was the "best" until TOML came around. If a service you are using needs JSON/YAML, you can generate it. But, stick with a configuration file format that is suitable for humans for actual configuration.

Also, PSA, neither JSON nor YAML files are good places to embed logic.

Also, another PSA, the fact that Pipfile is just a TOML file is just silly. Another point in Ruby's favor.

Re: YAML and Configuration Files

#62

Earlier quoted context omitted.

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.

you could allow python like comments and strip them with a regular expression substitution before parsing. Something like this. (it strips all the lines that start with whitespace, followed by #, followed by anything until the end of the line) cat cfg.json | sed -e 's/\s*#.*$//g' | jq . Allowing multiple lines is more complicated, can't do that with regex alone.

There are lots of ways to implement it. The problem is that one of JSON's strengths is its ubiquity: every language under the sun has half a dozen different battle-tested parsers for it. Clients and servers and everything in-between have first-class support out of the box. You can even paste it directly into JavaScript as valid code.

If anybody short of a standards body tries to expand the spec, you lose out on most of that.

Re: YAML and Configuration Files

#63
I know that this won’t likely be a popular opinion but I really like the MSBuild configuration way with xml and interpolation. I have found I can even reason about fairly complex configurations without too much hassle. You can also debug them which is great. It’s not that it doesn’t have its warts it’s that it really does a good job for what it’s mean to: semi-programmable configuration. It’s also extensible.

However, it is of course extremely proprietary

Re: YAML and Configuration Files

#64
post #33

Earlier quoted context omitted.

> 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,…

>loads of other things I don't understand. also you can have multiple instances of yaml trees in one file, each one separated with -- . I think this makes it very confusing if used as a configuration language (they like to use yaml for configuration in kubernetes)

I mean sure but I’ve never seen any software actually use that feature in the wild except for “you’re allowed to concat your YAML files instead of separating them if you want.” Like I’ve never seen software require a certain number of documents in a file with different schemas.

Re: YAML and Configuration Files

#65
post #9

I think Cue[1] is a much more powerful and useful config format that also has the ability to generate validated JSON or YAML if needed. [1]: https://cuelang.org

Not sure if 'much more powerful' is a desirable feature for a configuration file language.

The ideal configuration format is really powerful and expressive for the author but resolves to a dead simple data structure for the consumer. If you need to template your config files for anything other than supplying external data it’s not expressive enough. I think YAML is closer than many of its contemporaries to this.

Re: YAML and Configuration Files

#66
post #33
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,…

If Dhall was more popular, would it meet your criteria?

Re: YAML and Configuration Files

#67
post #33

Earlier quoted context omitted.

> 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,…

If Dhall was more popular, would it meet your criteria?

[deleted]

Re: YAML and Configuration Files

#68
post #42
post #30

Earlier quoted context omitted.

Toml has unlimited nesting as well. There are also many formats that are "better json" that have comments, multiline strings, trailing commas etc. Such as hjson, json5 (and variants such as json6, jsonX, etc.) and hocon. As well as more sophisticated languages like jsonnet, dhal, and cue. Many of these can be "compiled" to JSON. There is plenty of competition, but for some reason, YAML seems to be the most popular.

TOML gets very weird as soon as you have more than one level of nesting.

It depends on the kind of nesting, cargo has multiple levels of nesting all the time and it's working well.

Through is you have thinks like object->list->object->list thinks can get weird without questions.

Still most time I had such complex configs I also often (not always) realized that I did something wrong and unnecessary complex...

Re: YAML and Configuration Files

#69
post #33
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,…

If you come up with a format, call it IJW. It just works.

Re: YAML and Configuration Files

#70
post #64

Earlier quoted context omitted.

>loads of other things I don't understand. also you can have multiple instances of yaml trees in one file, each one separated with -- . I think this makes it very confusing if used as a configuration language (they like to use yaml for configuration in kubernetes)

I mean sure but I’ve never seen any software actually use that feature in the wild except for “you’re allowed to concat your YAML files instead of separating them if you want.” Like I’ve never seen software require a certain number of documents in a file with different schemas.

i saw it being used in some CI system; it was very confusing.
Post reply on HN