What is this for? YAML in my experience is used for writing and maintaining config at some supposed sweet-spot between human-readable and machine-readable structure.
In my experience also, YAML is already too feature-laden for it's own good in this regard, when what people usually want is just a more human-readable JSON.
Using Yglu for config seems like a bad idea (the whole point of config is that it's not code!) - so what is it for?
For large, repetitive configurations (Kubernetes configs, CloudFormation templates, CI job configurations, etc) you often want ways to abstract and/or DRY your configurations. Kubernetes folks use mustache/jinja/Go templates via Helm, which is a real mess. CloudFormation builds its own (shitty) evaluation language on top of YAML. This presumably aims to improve on those sort of hacky solutions. I feel strongly that the "right" solution is either (1) generate a YAML config with Python/JS/etc or (2) use a terminating expression language (I think that may be what this is). Since (2) implies a much steeper learning curve for average developers, I opt for (1).
As for YAML itself, it is handy to have some advanced functionality in a non-turing complete serialization format for the sake of things like security. It's not perfectly analogous, but PostScript is an example of a format that ideally should have been just a descriptive format for the purposes it was intended for, but being Turing complete makes it a security risk
Dhall[1] is a similar concept, though instead of augmenting a particular format, it is an implementation of a simple pure functional programming language (with a very expressive type system which guarantees termination). Dhall programs can then be evaluated to several different formats (currently JSON, YAML and XML).
Dhall is awesome and rooted in the solid ML line. I wish pure functional programming langs were significantly growing in the industry. It would show signs of maturity but it is still currently a high-hanging fruit for many and traction is diluted in the impression of hobbyism or academism.
What can we bring for those dealing with YAML everyday? Hard to tell them "switch all your stuff to X". Easier to tell them "you can iteratively add functional expressions to your YAML". That's the point of Yglu. It's not about proposing a better Dhall or Jsonnet. It is about proposing better YAML-native tooling.
That is fascinating. I feel like I've seen this before and forgotten about. Really neat and I love that you can grab shared code from a CORS URI. That's great, especially for internal code sharing.
actually glanced over the blog post. so this is inspired by ytt, which is pretty cool.
However, I am not totally sure that the use of exclamation mark and question mark to start expressions makes it any more readable than embedding code inside comments.
Also not sure what a "single source for template values" means , since in ytt you can have multiple input sources
Hold on. YAML gained popularity as a nice syntax for JSON, which itself was a subset of JavaScript, a full programming language. Now, we are adding some computational capabilities back to YAML? Wouldn't it be better to just execute JavaScript to generate a JSON object and skip building a new language inside of YAML?
Compared to Helm and other common kubernetes templating solutions that try to use blind textual replacement in whitespace-sensitive language, this (or something like it) looks like a god-send.
I despise YAML but like Markdown. They serve different purposes. Markdown is a light-weight way to format prose. YAML is a config language. Markdown is pretty good at formatting prose. YAML is a disaster confusing syntax unsuitable for configs past about 100 lines.
We have a 1500 line YAML file for our test config because YAML is the one true method for setting up tests. The issues I've run into:
- Indentation errors. Luckily CircleCI has a YAML validator, but the fact that a validator is required isn't great.
- true, false, yes, no. Why?
- date and number coercion vs strings.
- YAML has aliases which in theory let you reuse config. Except you can't compose aliases, like have JavaTest inherit config from GitHubReporter and SlackReporter.
My view is that complex configs should be generated from a reproducible binary, preferable in a real programming language with loops, conditionals, and some form of easy composition. Dhall, jsonnet [2], or Cue [3] are all interesting languages in this space.
[+] [-] fredley|6 years ago|reply
In my experience also, YAML is already too feature-laden for it's own good in this regard, when what people usually want is just a more human-readable JSON.
Using Yglu for config seems like a bad idea (the whole point of config is that it's not code!) - so what is it for?
[+] [-] throwaway894345|6 years ago|reply
[+] [-] bitbang|6 years ago|reply
As for YAML itself, it is handy to have some advanced functionality in a non-turing complete serialization format for the sake of things like security. It's not perfectly analogous, but PostScript is an example of a format that ideally should have been just a descriptive format for the purposes it was intended for, but being Turing complete makes it a security risk
[+] [-] dddbbb|6 years ago|reply
[1]: https://dhall-lang.org/
[+] [-] lbovet|6 years ago|reply
[+] [-] leetrout|6 years ago|reply
[+] [-] iudqnolq|6 years ago|reply
I'm especially interested in jsonnet (https://jsonnet.org/) because of how thoroughly it's documented.
An example that produces three different config files:
[+] [-] sawmurai|6 years ago|reply
[+] [-] timw4mail|6 years ago|reply
[+] [-] IshKebab|6 years ago|reply
Worth reading this if you are considering using it: https://www.arp242.net/yaml-config.html
[+] [-] ainar-g|6 years ago|reply
[1] https://news.ycombinator.com/item?id=17359376
[+] [-] MockObject|6 years ago|reply
[+] [-] KaoruAoiShiho|6 years ago|reply
[+] [-] nkaviani|6 years ago|reply
looks like a very similar effort to ytt: https://get-ytt.io/
it seems like yaql is a different, potentially more limiting, scripting language, but otherwise similar efforts.
[+] [-] nkaviani|6 years ago|reply
However, I am not totally sure that the use of exclamation mark and question mark to start expressions makes it any more readable than embedding code inside comments.
Also not sure what a "single source for template values" means , since in ytt you can have multiple input sources
[+] [-] mv1|6 years ago|reply
[+] [-] dpc_pw|6 years ago|reply
[+] [-] pavon|6 years ago|reply
[+] [-] techntoke|6 years ago|reply
[+] [-] sa46|6 years ago|reply
We have a 1500 line YAML file for our test config because YAML is the one true method for setting up tests. The issues I've run into:
- Indentation errors. Luckily CircleCI has a YAML validator, but the fact that a validator is required isn't great.
- true, false, yes, no. Why?
- date and number coercion vs strings.
- YAML has aliases which in theory let you reuse config. Except you can't compose aliases, like have JavaTest inherit config from GitHubReporter and SlackReporter.
My view is that complex configs should be generated from a reproducible binary, preferable in a real programming language with loops, conditionals, and some form of easy composition. Dhall, jsonnet [2], or Cue [3] are all interesting languages in this space.
[1]: https://dhall-lang.org/ [2]: https://jsonnet.org/ [3]: https://news.ycombinator.com/item?id=20362951
[+] [-] moderation|6 years ago|reply
0. https://yaml.org/spec/1.2/spec.html
1. https://daringfireball.net/projects/markdown/index.text