I'm sure people will be happy to crucify me for throwing this out there but I don't see a big risk in just using JavaScript in most cases if you want something like that. You could use template literals to replicate the example.
Dhall: A Non-Repetitive Alternative to YAML
121–130 of 181 posts
Re: Dhall: A Non-Repetitive Alternative to YAML
#122Couple of contenders: - Jsonnet ( https://jsonnet.org/ ) - simpler syntax and less concepts to learn, just an extension of JSON. But no type checking. An open source offspring of Google's internal config language (GCL/BCL) - Cue ( https://github.com/cuelang/cue ) - a more ambitious attempt to fix GCL/BCL by replacing inheritance as the fundamental compositional primitive with constraint unification. Great thread comp…
i'll throw in one of my projects as a contender: ytt - YAML templating tool - https://get-ytt.io (check out live playground!).
it works with yaml structures (hence avoids text templating problems) and uses familiar python-like language, starlark, making quite easy to get started. it makes use of yaml comments to assign metadata/templating directives to yaml nodes, so it looks something like this:
#@ load("@ytt:data", "data")
#@ def labels():
app: echo
org: test
#@ end
kind: Pod
apiVersion: v1
metadata:
name: echo-app
labels: #@ labels()
spec:
containers:
#@ for/end echo in data.values.echos:
- name: #@ echo.name
image: hashicorp/http-echo
args:
- #@ "-text=" + echo.text
Re: Dhall: A Non-Repetitive Alternative to YAML
#123Couple of contenders: - Jsonnet ( https://jsonnet.org/ ) - simpler syntax and less concepts to learn, just an extension of JSON. But no type checking. An open source offspring of Google's internal config language (GCL/BCL) - Cue ( https://github.com/cuelang/cue ) - a more ambitious attempt to fix GCL/BCL by replacing inheritance as the fundamental compositional primitive with constraint unification. Great thread comp…
We tried to introduce Jsonnet at our org. It failed miserably because ops kept mistaking the name for JSON which they hated. (International multilingual team). It was a real shame because ops then implemented some features of Jsonnet via scripts to to parse and merge YAML. What was 0 LOC in Jsonnet is now about 300 LOC plus custom CI checkers, all because of a marketing problem.
If I go to the mentioned Jsonnet homepage it says "A simple extension of JSON". The graphic explains its relation to JSON. The example looks awfully similar to JSON.
What I don't understand is the following: config files are read by text editors, and in the end, by human beings. Because of the latter they should have certain traits. We must agree on the importance of these traits before we can settle on a standard.
For me, important features are that they must be readable, and easily editable. They must be readable with a certain text editor (vi) for backwards compatibility. So that means it shouldn't require syntax highlighting or schema. Well, these 2 simple requirements of mine rule out anything remotely resembling JSON.
It just appears to me that JSON is for JavaScript developers, YAML for Python developers, and Dhall for ML (the whole family I suppose, not just Haskell) developers.
Well then if we're going that route then perhaps all we need is some kind of glue between text config and binary config (which reminds me of Systemd...). Ie. that it accepts multiple config file formats.
Re: Dhall: A Non-Repetitive Alternative to YAML
#124Dhall is an awesome tool to have in your DevOps tool belt - we're heavy dhall users at meshcloud [0] and couldn't be happier about it. We picked it after evaluating a long list of contenders (yaml madness with anchors, jsonnet, ksonnet, j2/jinja, a hacked ejs compiler [1] and some more I forgot). It's so good we're looking into how we can give back/donate to the project.
Dhall elegantly solves a major challenge: configuration management at scale. We build a multi-cloud management platform, which serves DevOps teams, IT Governance, Controlling and IT Management in large enterprises. That means we're an integration solution for a lot of things, so we need to be highly configurable. Because we also manage private clouds (a la OpenStack, Cloud Foundry, OpenShift etc.), we often run on-premises and operate our software as a managed service. Using dhall allows us to _compile and type check_ all our configuration for all our customers before rolling things out. We use dhall to compile everything from terraform/ansible, kubernetes templates, spring config, to concourse ci pipelines and customer-specific reference data to load into our product. Since adopting dhall earlier this year, we measurably reduced our deployment defect rate and re-gained the ability to safely refactor configuration.
It takes a little time to get used to, but we appreciate that it's highly opinionated around formatting and "how to do things" - somewhat in the same way as golang is. It has certainly helped that we had a member with haskell experience on the team, as dhall is built in haskell and the syntax feels familiar.
Plug: if you're looking for a job working with dhall, reach out :-)
- 0: https://meshcloud.io - 1: https://github.com/Meshcloud/ejs-compiler
Re: Dhall: A Non-Repetitive Alternative to YAML
#125To me, worrying about config files seems like the ultimate exercise in bikeshedding. You either need a simple list of items (eg. dependencies) or key/value pairs. Use a text file or yml or json or whatever. Or you need templating, the use of functions, etc, like dhall provides. But then, why not use the language you're already using for the rest of your project, or a bash script to export some variables? Might sound…
> You either need a simple list of items (eg. dependencies) or key/value pairs. Use a text file or yml or json or whatever.
You clearly haven't wrestled with kubernetes configuration files.
Reams and reams of YAML, heavily indented to represent umpteen nested objects.
Templating, bash scripts, using your favourite language to roll your own config generator - these are all well trodden approaches that fail to scale.
Official shitshows like Helm have come along with nothing more innovative to offer than templated YAML. The next version uses lua to generate config, but I remain skeptical given previous design choices.
We can question whether kubernetes has pushed the dial too far towards necessitating mountains of config, but for now it is most definitely a problem for us users.
Re: Dhall: A Non-Repetitive Alternative to YAML
#126This isn’t an alternative to yaml. It’s a yaml generator. To me it’s not competing with yaml it’s competing with python or Haskell, and i’d argue that putting yet another language in your stack just for generating config files is added unneeded complexity.
And sure while both python and Haskell are Turing complete, how often do we actually run into issues when generations flat config files? I mean I’ve never had that issue, and I’ve never caught myself thinking “if only there was a nice way to limit myself to a non Turing complete subset of python/Haskell”...
Re: Dhall: A Non-Repetitive Alternative to YAML
#127Re: Dhall: A Non-Repetitive Alternative to YAML
#128How far does "non turing completeness" really get you in this context? It looks easy to write a program in this language that will take longer than the age of the universe to evaluate and whose result can't be represented explicitly without collapsing the galaxy into a black hole. How much comfort can you take in the fact that you know it doesn't diverge?
How would you write such a program?
Re: Dhall: A Non-Repetitive Alternative to YAML
#129This isn’t an alternative to yaml. It’s a yaml generator. To me it’s not competing with yaml it’s competing with python or Haskell, and i’d argue that putting yet another language in your stack just for generating config files is added unneeded complexity. And sure while both python and Haskell are Turing complete, how often do we actually run into issues when generations flat config files? I mean I’ve never had that…
That's kind of like saying C isn't an alternative to assembly, it's an assembly generator.
Re: Dhall: A Non-Repetitive Alternative to YAML
#130To me, worrying about config files seems like the ultimate exercise in bikeshedding. You either need a simple list of items (eg. dependencies) or key/value pairs. Use a text file or yml or json or whatever. Or you need templating, the use of functions, etc, like dhall provides. But then, why not use the language you're already using for the rest of your project, or a bash script to export some variables? Might sound…
> You either need a simple list of items (eg. dependencies) or key/value pairs. Use a text file or yml or json or whatever. You clearly haven't wrestled with kubernetes configuration files. Reams and reams of YAML, heavily indented to represent umpteen nested objects. Templating, bash scripts, using your favourite language to roll your own config generator - these are all well trodden approaches that fail to scale. O…
My favorite is when people write scripts that concatenate YAML files in such a way that you have to be really careful about how this one file always needs to be indented by 12 spaces otherwise everything breaks in horrible ways.