Pick a JSON templating engine

[mccalluc]

Options:

• json-template-engine (= jsonteng ?)
• jsonnet
• emrichen
• jinja tojson

[mccalluc]

additional options from: google/jsonnet#711

Evaluations:

• jinja would require us to remember to always include a |tojson filter, and if we forget we're just injecting strings.
• json-template-engine:
  • good: Python library, seems to be active, institutional support (vmware), interface matches our needs, good CLI documentation.
  • bad: No documentation of use as python library, no issues on github.
• jsonnet
  • good: Documentation, institutional support (google), python binding
  • bad: overkill: It's really a full language. For templating, instead of $ you need std.extVar.
• emrichen
  • good: Actively developed, interface seems ok
  • bad: Module interface is underdocumented, oriented to yaml rather than json.
• hocon/pyhocon: Not able to provide variables, except for envvars? The goal seems to be to expand the abbreviation syntax from yaml.
• dhall-python: Overkill, python implementation is incomplete.
• starlark: full language

[sparkprime]

Big difference between Jsonnet and Starlark is the latter really only has functions whereas in Jsonnet you can define data structures in terms of other datastructures (it's more data-oriented). If you use Jsonnet, use the go-jsonnet port as it's much faster and where we want to continue development. As for std.extVar you can also write your configs in the form of a function that accepts parameters, but then you have to thread them through into other files. If you do use std.extVar you can do local x = std.extVar("x"); at the top of your file in order to keep it concise.

[mccalluc]

Thanks for the feedback! In #29 I'm proposing that we use jsonnet... for the moment, the python port, but if this work continues we'll keep Go in mind. I may switch to the x = std.extVar("x"); at the top that you suggest... it feels a little more explicit about what's going on than the TLA syntax.