skylark
libyaml
skylark | libyaml | |
---|---|---|
1 | 1 | |
1,184 | 893 | |
- | 1.5% | |
0.0 | 3.6 | |
about 5 years ago | 24 days ago | |
Go | C | |
BSD 3-clause "New" or "Revised" License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
skylark
-
YAML and Configuration Files
My stance is that YAML is a good format for configuration management and generation -- it's wonderful at filling gaps as your deployment model increases in complexity to provide a mechanism to "render" your configuration -- much like Skylark [1] does (derived from Google's internal GCL).
YAML ends up being a powerfully declarative model [2] for the state of a data structure, rather than a straight representation, ironically often enough being used in turn for an imperative model like in Ansible [3]. Definitely friendlier than JSON. But personally, I really like YAML because it lets me compose using a traits/mixins-like model using & and , which allows for verbose, structured configuration inputs but concise configuration files.
docker-compose YAML files extension fields [4], imo, are a great example of this type of model in action. When you leave this much pre-deserialization flexibility in your configuration representation, it makes building cool stuff like docker-compose ECS support x-aws- extension keys [5] and other plugin system-type capabilities much more straightforward than, for example, adding a new language feature to HCL.
[1]: https://github.com/google/skylark
libyaml
-
YAML and Configuration Files
Currently, my main concern with YAML is that, by the spec, comments are not attached to a particular node (see https://yaml.org/spec/1.2/spec.html#id2767100). As a result, a lot of YAML parsers (like https://github.com/yaml/libyaml and https://github.com/chyh1990/yaml-rust) only filter out the comments during the parsing phase. This makes it less than ideal for a use-case where the configuration file is expected to be modified by both programs and humans.
TOML makes it more trivial to associate comments with a node. This is mainly because the language is simpler though, as the spec is not explicit about that (https://github.com/chyh1990/yaml-rust).
What are some alternatives?
yaml-rust - A pure rust YAML implementation.
ytt - YAML templating tool that works on YAML structure instead of text
hjson-js - Hjson for JavaScript
cue - The home of the CUE language! Validate and define text-based and dynamic configuration
KeenWrite - Free, open-source, cross-platform desktop Markdown text editor with live preview, string interpolation, and math.
cue - CUE has moved to https://github.com/cue-lang/cue
json5 - JSON5 — JSON for Humans
strictyaml - Type-safe YAML parser and validator.