AWS – The YAML Way(github.com)
github.com
AWS – The YAML Way
https://github.com/tuananh/aws-the-yaml-way
7 comments
I haven’t seen it explicitly banned, but the Operational Readiness templates does have a question about that which has to be answered for all product and feature launches. I guess some orgs may just have banned it outright though.
Overreaction? Let's hypothetically consider yaml+, with the definition:
* easy to create a simple script to validate the end-of-file dot line.
* easy to create a presubmit check to validate yaml+
* easy for an editor to syntax check the end-of-file dot line.
Assuming there are other redeeming qualities of YAML, the truncated YAML problem can be solved with minimal effort.
yaml+ = yaml "\n" "."
* easy to create a simple script to validate the end-of-file dot line.
* easy to create a presubmit check to validate yaml+
* easy for an editor to syntax check the end-of-file dot line.
Assuming there are other redeeming qualities of YAML, the truncated YAML problem can be solved with minimal effort.
- Define a new file format, yaml-plus.
- Create a parser for the new yaml-plus format across all supported languages.
- Migrate all build processes to handle yaml-plus with the new parser. In a large-org, it's likely impossible to track down all the usages of YAML. Someone will have a bash script that hasn't been touched for 10 years that implements an adhoc YAML parser.
- Modify the YAML mode for all supported editors to support the new syntax.
This doesn't sound like minimal effort. Mandating that all new configs must be JSON (or similar, newer alternative like cue) is way easier since JSON already exists.
- Create a parser for the new yaml-plus format across all supported languages.
- Migrate all build processes to handle yaml-plus with the new parser. In a large-org, it's likely impossible to track down all the usages of YAML. Someone will have a bash script that hasn't been touched for 10 years that implements an adhoc YAML parser.
- Modify the YAML mode for all supported editors to support the new syntax.
This doesn't sound like minimal effort. Mandating that all new configs must be JSON (or similar, newer alternative like cue) is way easier since JSON already exists.
Not really. Team X uses Java? Someone on the team takes 1 hour to create YamlPlus.java, submits to the monorepo. Now team X + all the other 100(0) teams that use Java have access to a yaml+ parser. Same with Golang, JS, Python, C++, cli check, presubmit check, and we are running out of supported languages.
The argument that no incremental change is ever possible because it has to update every related legacy usage is a recipe for organizational paralysis.
The argument that no incremental change is ever possible because it has to update every related legacy usage is a recipe for organizational paralysis.
Since YAML tries to be a superset of JSON (it’s not, but it tries), wrapping your whole file in a pair of braces solves your truncated file problem. If the closing brace isn’t there, the parser will (should) error
YAML is like Python without the effectiveness.
I sort of remember it was a contributing factor to a significant outage. A YAML config file was truncated and given partial configuration and otherwise falling back to default config, it put a system into a bad state.
YAML was banned by some teams (and discouraged in most teams), because you can't detect a truncated file, like you can with XML or JSON.