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

71–80 of 96 posts

Re: YAML and Configuration Files

#71

Post by Aloha »

secondcoming wrote: post #18
u801e wrote: post #6

Earlier quoted context omitted.

Compared to yaml or ini formats, JSON is arguably harder to read and definitely harder to write due to having to keep track of brackets, commas, and/or quotes. Ideally, a configuration file should be easy to read and write/modify by a user of the application. A lot of applications just stick with ini like formats because it meets both requirements.

Maybe it's because I've written C++ for years, but give me brackets over significant whitespace any day. If anything, YAML is harder to read because the indentation is important, yet deliberately invisible.

Agree.

Whitespace with inconsistent rules is awful.

Re: YAML and Configuration Files

#72

Post by mh0pe »

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…

My stance is that YAML is a good format for configuration management and generation -- it's wonderful at filling gaps as your deployment model increases in complexity to provide a mechanism to "render" your configuration -- much like Skylark [1] does (derived from Google's internal GCL).

YAML ends up being a powerfully declarative model [2] for the state of a data structure, rather than a straight representation, ironically often enough being used in turn for an imperative model like in Ansible [3]. Definitely friendlier than JSON. But personally, I really like YAML because it lets me compose using a traits/mixins-like model using & and *, which allows for verbose, structured configuration inputs but concise configuration files.

docker-compose YAML files extension fields [4], imo, are a great example of this type of model in action. When you leave this much pre-deserialization flexibility in your configuration representation, it makes building cool stuff like docker-compose ECS support x-aws-* extension keys [5] and other plugin system-type capabilities much more straightforward than, for example, adding a new language feature to HCL.

[1]: https://github.com/google/skylark

[2]: https://en.wikipedia.org/wiki/YAML#Advanced_components

[3]: https://docs.ansible.com/ansible/latest/user_guide/playbooks...

[4]: https://docs.docker.com/compose/compose-file/compose-file-v3...

[5]: https://docs.docker.com/cloud/ecs-integration/#rolling-updat...

Re: YAML and Configuration Files

#73

Post by MichaelMoser123 »

brundolf wrote: post #62
MichaelMoser123 wrote: post #55

Earlier quoted context omitted.

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…

i think you can possibly define how you want to use json for a configuration file; json by itself is not much more than javascript objects/maps, defined as a data format. I frankly don't think that you need to be too pious about standard compliance if dealing with a cofiguration format for your application.

Re: YAML and Configuration Files

#74

Post by thayne »

fanf2 wrote: post #42
thayne wrote: 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.

Nesting multiple levels of tables is pretty simple, you just have sections that look like [a.b.c]. It's different than Json, but IMO easier to read and navigate.

Unfortunately it doesn't handle c arrays of arrays of tables very well.

Re: YAML and Configuration Files

#76

Post by bschwindHN »

brundolf wrote: post #38
amirkdv wrote: 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,…

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.

JSON5 is nice. I use it for all our configuration files at work after evaluating a large list of configuration file formats. I've never really run into any frustration using it, whereas YAML, TOML, and others drive me crazy when I need to represent nested structures or arrays.

https://json5.org/

Re: YAML and Configuration Files

#77

Post by bschwindHN »

kumarvvr wrote: post #75

I always wondered, why XML is not used by developers. I use it for my programs. The combination of attributes and data within nodes, to me, has been very useful.

It's a slog to write, harder to parse, and you have to make more decisions (do I put this in the node's attribute, or as a child node?).

Maven had pom.xml files for declaring dependencies. Very few developers enjoyed editing those, and you don't see many XML-based config files these days for a reason.

Re: YAML and Configuration Files

#78

Post by FrancoisBosun »

brundolf wrote: post #38
amirkdv wrote: 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,…

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.

What about a key named “_comment”, or something similar? Of course, the underlying software must ignore unknown keys, so it’s not a full win anyway.

Re: YAML and Configuration Files

#79

Post by travisjungroth »

derefr wrote: post #54
travisjungroth wrote: post #41

Earlier quoted context omitted.

What do you mean by “exploded AST”? What’s a “structural-initialization literal”?

Structural initialization is when you define a struct (as opposed to a scalar) by directly declaring the values of its (potentially-private!) named fields. For example, in Elixir, this is a structurally-initialized MapSet literal: %MapSet{map: %{}, version: 2} This is as opposed to a factory-method-initialized literal, going through a functional API that can hide the inner workings of the ADT produced: MapSet.new Or,…

Thanks for explaining. I'm not sure that's laughed at in every language. It's standard in Clojure to just define things as maps, lists, etc. I actually think it's a pretty good idea.

Your examples, datetimes and regex, make the DSL option seem nice. In picking good examples you picked ones I'd be familiar with. But that's sort of the trick. If something is completely new to me, I'd much rather have it blown up.

Re: YAML and Configuration Files

#80

Post by petre »

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

I used to think that before I had to edit the ejabberd.yml config file. Now I think it's only remotely useful as a subset to use in Jelkyll headers.

Just use TOML for configuration instead.

Post reply on HN