Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

One of my favorite bugs of all time, which turns out to be a pretty common yaml bug (the article touches on a similar example), was when we used yaml to configure some localizable data. Everything worked fine until Norway came online. Sweden worked fine, so did Denmark and every other country, but the app crashed when it loaded the config for Norway.

Turns out the country code for Norway, "no", is interpreted as boolean false when unquoted in yaml.

View on HN

YAMLLint is nice for this use case.

https://github.com/adrienverge/yamllint

It can be configured to require strict string quoting.

https://yamllint.readthedocs.io/en/stable/rules.html#module-...

And to explicitly restrict bools to only `true` and `false`.

https://yamllint.readthedocs.io/en/stable/rules.html#module-...

If you need a linter for you conf file, something is wrong.

We have schemas for some of our configs which is a level beyond linting. Trying to spread this more and more. Removes some classes of load errors with services.

Trying to get to almost jsonschema level without the complexity of specification and reuse with the actual code

JSON Spec for YAML files is neither ideal as there is no standard way to indicate, within the YAML file itself, which JSON schema to be read by parsers and editors to validate the document.

Sorry, but YAML is a disaster and YAML Lint and JSON Schema are weak attempts to improve it.

I'd be happy if YAML evolved to a true schema support, use of brackets or some other tip so white space wouldn't be meaningful, and silly things removed like three hundred ways to define Boolean values.

Is there some correlation between wrongness of conf files, and the usage of a linter?

Or you're just conceding that software is imperfect and trying to make it as error free as possible is the objective.

Why? Everything should be linted and validated. If it's in the repository, then it's "code".

If it's a config file, chances are it's not in your repo but at the customer's site. Are you going to ship the linter to production too?

Shouldn't the customer either be competent at configuring the system themselves or let somebody else do it (who will then ensure that the config is valid)?

Edit: I suppose you mean that the config format should be "user friendly". I guess it should, but I have personally had far fewer problems with YAML than with TOML.

I disagree. XML and JSON both have linters, and correctly so ; they are complex.

XML is way worse. An errant tab can totally screw over your config with no warnings. I've never needed a linter or had much trouble with JSON, explicit delimiters go a along way.

What? How? Tabs don't affect how xml is parsed. In fact it's rather tricky to have significant whitespace in an xml document.

I ran into this my self and was rather taken back by this. I get what they’re trying do here but the not obvious value of something that looks like a string (or maybe a number) is rather frustrating and seems like a poor design decision for Something generally used for configuration.

I had that problem with XML. Now I do not use XML myself, but I wrote a tool to load it and convert some values to boolean.

I wrote it to read true/false, but then there were some test cases that failed. Turns out, the schema also allows yes/no and 1/0 as synonyms.

I used a JS object as a map back in the day for image recognition results, for some reason it kept breaking the app for pictures of prototypes...

Are you saying you were using "__proto__" as a key?

Suggesting that you were using a function as a map and "prototype" as the key seems even more made up.

I think I did something similar using "static" 20 years ago.

Check out my improvement upon yaml spec: https://github.com/keymone/aml-spec/commit/9c1fa50c28525a7b3...

But it is because you do not use a yaml serializer.

If you use a template you have to put "" for strings.

I have been using yaml for years (mostly as a user, not as a dev) and I’ve never heard anyone mention a yaml serializer. Is this common practice? Wouldnt the yaml serializer have the same locality issues, or is it more strict?

A serialiser is just a program/library that takes a data structure and emits YAML. GP criticises GGP for putting the value no manually into the file and thus causing a bug instead of letting a piece of specialised software deal with the correct form (here: quoted string).

If your human-writable format requires a serializer to avoid unexpected types, it's not human-writable. If your human-readable format requires special cases for certain keywords but treats others as strings, it's not human-readable.

> If your human-writable format requires a serializer to avoid unexpected types, it's not human-writable.

That sounds like there are no human-writable formats.

> If your human-readable format requires special cases for certain keywords but treats others as strings, it's not human-readable.

That I can 100% support; sometimes needing to quote strings is a recipe for disaster.

> That sounds like there are no human-writable formats.

I'm not sure why it sounds that way. There are formats where types are explicit, either by stating them or by their delimiters or by their contents.

No, it is because that part of yaml spec is plain dumb.

Reply on news.ycombinator.com