3 ms·

> Regardless of whether YAML 1.2 has been (or will be) widely adopted, it does not help those who want to parse a JSON document with a YAML parser. Who are the

> Regardless of whether YAML 1.2 has been (or will be) widely adopted, it does not help those who want to parse a JSON document with a YAML parser. Who are these hypothetical lunatics?

coderjames 1y ago
> those who want to parse a JSON document with a YAML parser. I've done it. We already had a YAML parser in an internal library I maintain since we were already ingesting YAML files for other reasons, so when we later added new files for a different reason that someone decided should be in JSON instead, it was easier and cleaner to keep using the existing YAML parser we already had incorporated rather than add a separate JSON parser along side it.
randallsquared 1y ago
Anyone who wants to convert a piece at a time to yaml, but would prefer to just use a single parse step (as suggested by one of the quoted bits in the article). It's a niche case, but sensical.
zamalek 1y ago
You want to use a machine to create a document for something that accepts JSON. e.g. Something I was playing around with was having a github workflow that generates a github workflow. Or generating docker compose files.
makeitdouble 1y ago
It works in most trivial cases, so I'm assuming it's widely done irl. Imagine building some small app that reads external config file. You personally only care about yaml files, but your avid users ask for official json support as well because of a few of their files. It's not high priority, but as you remember the old saying, json is just a subset, so you try a bunch of files, confirm it works well enough, and decide to pipe JSON files to your yaml parser as well. Done and done. And it's not so big block of code or anything that jumps at the users, the dev just happens to share a parser between formats.
MyOutfitIsVague 1y ago
Ruby on Rails has a databases.yml that is preprocessed by ERB. I often do something like: field: <%= File.read('/foo/bar').to_json %> Though I have myriad criticisms of YAML, this article's arguments are not a concern at all if you can ensure that your YAML parser always uses 1.2 regardless of any %YAML directive.
- 0xbadcafebee 1y ago
  As someone who has written a lot of YAML-compatible software, this is my biggest takeaway: every single YAML-parsing tool is incompatible with each other (in some way). If two tools work together, it's an accident. They will work for a while until someone tries to do something with one tool that the other tool doesn't like. If all you do with YAML is serialize data, from one tool, to the exact same tool, it's fine. For all other purposes you should seek a different data format (if you don't want to deal with the eventual bugs). (note that I don't mean parser/library, I mean tool. the tool using the library will often use or not-use certain options which increases the complexity of the interactions and leads to more possible failures)
osigurdson 1y ago
Kubernetes is a good example. Objects can be read / written as json or yaml interchangeably.
- antonvs 1y ago
  It’s not an example at all. It uses different parsers and renderers for each format.
  - osigurdson 1y ago
    The parent comment asks the question "Who are these hypothetical lunatics?". I don't know what today's Kubernetes parser does but it seems plainly obvious that Kubernetes would be a consumer of "YAML as JSON superset" parser if it exists. It isn't as though users are expressing different things with JSON than they are with YAML.
ethan_smith 1y ago
Configuration systems like Kubernetes and Docker Compose use YAML parsers that accept JSON as input, allowing users to write in either format without changing the tooling.
- dathinab 1y ago
  but the things is there is a difference between 1) a parser which can handle both (based on detecting both and then switches the parsing depending on it) 2) a parser which is made for YAML and happens to be able to parse JSON
williamjackson 1y ago
I don’t like writing YAML. I like writing Python. So I write Python that generates YAML config files. JSON is in the standard library but YAML isn’t. So I generate JSON and name the file “file.yaml”. GitHub Actions, Dependabot, and Docker Compose never complain.
jaredklewis 1y ago
For real. You can find hardened, optimized JSON parsers for every runtime worth running. Hard to think of why you would want to avoid all those JSON parsers and use a YAML one to parse JSON.
dathinab 1y ago
people stuck with sub-par tooling (weather that's because of laziness, better tooling not being available/integrated, not know, not being usable or them being stuck on a ideological delusion where they insist on not using it doesn't really matter) like sub-par tooling is one of the 2 main reason of when it comes to problems with config or data serialization format (bugs, strange edge cases, etc.) the other is people obsessing with handling things the exact same way, which might looking similar from far away but have major different details/constraints/dynamics when you look closely at them. (like config parsing vs. data deserialization vs. ad-hoc languages on top of a config format)
pavel_lishin 1y ago
Ah, there y'all are.

> Regardless of whether YAML 1.2 has been (or will be) widely adopted, it does not help those who want to parse a JSON document with a YAML parser. Who are these hypothetical lunatics?

coderjames 1y ago

> those who want to parse a JSON document with a YAML parser. I've done it. We already had a YAML parser in an internal library I maintain since we were already ingesting YAML files for other reasons, so when we later added new files for a different reason that someone decided should be in JSON instead, it was easier and cleaner to keep using the existing YAML parser we already had incorporated rather than add a separate JSON parser along side it.

randallsquared 1y ago

Anyone who wants to convert a piece at a time to yaml, but would prefer to just use a single parse step (as suggested by one of the quoted bits in the article). It's a niche case, but sensical.

zamalek 1y ago

You want to use a machine to create a document for something that accepts JSON. e.g. Something I was playing around with was having a github workflow that generates a github workflow. Or generating docker compose files.

makeitdouble 1y ago

It works in most trivial cases, so I'm assuming it's widely done irl. Imagine building some small app that reads external config file. You personally only care about yaml files, but your avid users ask for official json support as well because of a few of their files. It's not high priority, but as you remember the old saying, json is just a subset, so you try a bunch of files, confirm it works well enough, and decide to pipe JSON files to your yaml parser as well. Done and done. And it's not so big block of code or anything that jumps at the users, the dev just happens to share a parser between formats.

MyOutfitIsVague 1y ago

Ruby on Rails has a databases.yml that is preprocessed by ERB. I often do something like: field: <%= File.read('/foo/bar').to_json %> Though I have myriad criticisms of YAML, this article's arguments are not a concern at all if you can ensure that your YAML parser always uses 1.2 regardless of any %YAML directive.

0xbadcafebee 1y ago
As someone who has written a lot of YAML-compatible software, this is my biggest takeaway: every single YAML-parsing tool is incompatible with each other (in some way). If two tools work together, it's an accident. They will work for a while until someone tries to do something with one tool that the other tool doesn't like. If all you do with YAML is serialize data, from one tool, to the exact same tool, it's fine. For all other purposes you should seek a different data format (if you don't want to deal with the eventual bugs). (note that I don't mean parser/library, I mean tool. the tool using the library will often use or not-use certain options which increases the complexity of the interactions and leads to more possible failures)

osigurdson 1y ago

Kubernetes is a good example. Objects can be read / written as json or yaml interchangeably.

antonvs 1y ago
It’s not an example at all. It uses different parsers and renderers for each format.
- osigurdson 1y ago
  The parent comment asks the question "Who are these hypothetical lunatics?". I don't know what today's Kubernetes parser does but it seems plainly obvious that Kubernetes would be a consumer of "YAML as JSON superset" parser if it exists. It isn't as though users are expressing different things with JSON than they are with YAML.

ethan_smith 1y ago

Configuration systems like Kubernetes and Docker Compose use YAML parsers that accept JSON as input, allowing users to write in either format without changing the tooling.

dathinab 1y ago
but the things is there is a difference between 1) a parser which can handle both (based on detecting both and then switches the parsing depending on it) 2) a parser which is made for YAML and happens to be able to parse JSON

williamjackson 1y ago

I don’t like writing YAML. I like writing Python. So I write Python that generates YAML config files. JSON is in the standard library but YAML isn’t. So I generate JSON and name the file “file.yaml”. GitHub Actions, Dependabot, and Docker Compose never complain.

jaredklewis 1y ago

For real. You can find hardened, optimized JSON parsers for every runtime worth running. Hard to think of why you would want to avoid all those JSON parsers and use a YAML one to parse JSON.

dathinab 1y ago

people stuck with sub-par tooling (weather that's because of laziness, better tooling not being available/integrated, not know, not being usable or them being stuck on a ideological delusion where they insist on not using it doesn't really matter) like sub-par tooling is one of the 2 main reason of when it comes to problems with config or data serialization format (bugs, strange edge cases, etc.) the other is people obsessing with handling things the exact same way, which might looking similar from far away but have major different details/constraints/dynamics when you look closely at them. (like config parsing vs. data deserialization vs. ad-hoc languages on top of a config format)

pavel_lishin 1y ago

Ah, there y'all are.