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

51–60 of 96 posts

Re: YAML and Configuration Files

#51

Post by jimmygrapes »

simonw wrote: post #19
Zamicol wrote: post #8

Earlier quoted context omitted.

And JSON5. https://github.com/json5/json5-go

What a delightfully readable example of a hand-rolled lexer and parser that is.

I thought you were being sarcastic, but I think I just finally learned how lexers and parsers work by reading the code, and I don't even know Go.

Re: YAML and Configuration Files

#52

Post by beached_whale »

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.

* C# - builtin via JsonCommentHandling, JsonSerializerOptions.AllowTrailingCommas - Newtonsoft via CommentHandling, trailing out of the box

* C++ - Boost.JSON/RapidJSON/DAW JSONLink have options for both, nlohmann has an option to allow comments

* Python, I only know doing it via jsmin first

* Javascript, use jsmin also

These are the ones I have used or seen. It comes up so often that parser writers get issues over and over until they support them. nlohmann did not for years. But people want them for config files and such. Them being an extension is nice in that they are not officially supported and how they are handled isn't specified.

Re: YAML and Configuration Files

#53

Post by derefr »

fanf2 wrote: post #47
derefr wrote: post #7

I think I get what the article is saying. I don't think they expressed it very well. Here's a concrete example of what I think they're complaining about. From a Kubernetes Deployment manifest: - name: DATABASE_URL valueFrom: secretKeyRef: name: db-conn key: uri That valueFrom.secretKeyRef.{name, key} structure is an "exploded AST" — something that in any programming language, you'd be chastised for writing out as a s…

I guess the Elixir "custom sigil" is a generalized version of the Ruby or Perl special quoting styles for things like regexes or shell commands? There are at least a couple of prominent versions of that: a great dynamic language version is JavaScript template literals https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... >; or in the static language world there's C++ user-defined literals https://en.cpprefe…

Right. Elixir's sigils (https://elixir-lang.org/getting-started/sigils.html) are just a macros in the current namespace of name name pattern sigil_[letter], where writing ~x/foo/ or ~x(foo) etc., evaluates the macro sigil_x("foo") at compile-time.

The JavaScript equivalent with tagged template literals isn't the same, because it isn't a macro, and so the template function has to run at runtime. As such, these are no longer literals (i.e. pure data) per se.

The C++ equivalent is closer, if-and-only-if the user-defined literal operator function call is a constexpr that gets pre-evaluated.

Re: YAML and Configuration Files

#54

Post by derefr »

travisjungroth wrote: post #41
derefr wrote: post #7

I think I get what the article is saying. I don't think they expressed it very well. Here's a concrete example of what I think they're complaining about. From a Kubernetes Deployment manifest: - name: DATABASE_URL valueFrom: secretKeyRef: name: db-conn key: uri That valueFrom.secretKeyRef.{name, key} structure is an "exploded AST" — something that in any programming language, you'd be chastised for writing out as a s…

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, compare and contrast a structurally-initialized literal with a DSL-expressed literal:

    %DateTime{ calendar: Calendar.ISO, day: 14, hour: 23, microsecond: {121432, 6}, minute: 57, month: 8, second: 22, std_offset: 0, time_zone: "Etc/UTC", utc_offset: 0, year: 2021, zone_abbr: "UTC" }
vs.

    ~U[2021-08-14 23:57:22.000000Z]
Note that in the first case (structural initialization), if there were any other complex non-scalar objects nested within the main one, you'd have to define those too. It's a forced encoding of an Abstract Syntax Tree representation of the structure of the data; but it's an AST that's "exploded" or "cross-sectional" — one that has no functions, no ability to encapsulate/abstract.

Here's a snippet from https://yaml.org/YAML_for_ruby.html#perl_regexps:

    !perl/regexp: 
      REGEXP: "R[Uu][Bb][Yy]$" 
      MODIFIERS: i
Wouldn't it be less annoying to both read and write that in a YAML document if it were expressed the way you'd expect — as:

    /R[Uu][Bb][Yy]$/i
...where YAML itself would know to parse the latter as if it were the former, and to generate the latter in place of the former (for this, and an exclusive few other common structurally-initialized types that constantly get represented in YAML documents)?

Re: YAML and Configuration Files

#55

Post by MichaelMoser123 »

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.

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.

Re: YAML and Configuration Files

#57

Post by scrollaway »

sofixa wrote: post #40
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,…

HCL does all of those. TOML is pretty close as well.

HCL is neither acceptably readable nor does it just work everywhere. TOML is getting there though yeah.

Re: YAML and Configuration Files

#58

Post by BFLpL0QNek »

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 especially, the config files are simple and concise.

TOML is my preference if I need a config file, it’s easy to read/write and reasonably expressive.

Re: YAML and Configuration Files

#59

Post by MichaelMoser123 »

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

>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)

Re: YAML and Configuration Files

#60

Post by dheera »

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

Besides the above (especially comments), YAML also has one huge advantage for configuration files and that is clean diffs.

JSON's lack of support for trailing commas messes up diffs.

Post reply on HN