skylark
yaml-rust
skylark | yaml-rust | |
---|---|---|
1 | 4 | |
1,184 | 597 | |
- | - | |
0.0 | 0.0 | |
about 5 years ago | about 1 month ago | |
Go | Rust | |
BSD 3-clause "New" or "Revised" License | Apache License 2.0 |
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
yaml-rust
-
Project idea: port markdownlint to Rust
Either https://github.com/chyh1990/yaml-rust or https://github.com/dtolnay/serde-yaml for parsing the YAML config file that markdownlint uses
-
Borrow checker not liking recursive walk through a HashMap
Here's the Rust code so far -- the commented portions are my intent via pseudocode. This is part of an implementation where there's a _yaml_hash member that points to yaml_rust's underlying LinkedHashMap. (Also using anyhow's bail! and Result.)
-
How to deal with unmaintained crates? (eg. yaml-rust)
The first thing I did was to find the crate yaml-rust and it seems it isn't really maintained anymore. It has not been updated in a year and there's a lot of PR's and unresolved issues, the CI is broken... So here is my open ended question.
-
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?
libyaml - Canonical source repository for LibYAML
serde-yaml - Strongly typed YAML library for Rust
ytt - YAML templating tool that works on YAML structure instead of text
serde - Serialization framework for Rust
cue - The home of the CUE language! Validate and define text-based and dynamic configuration
strictyaml - Type-safe YAML parser and validator.
hjson-js - Hjson for JavaScript
cue - CUE has moved to https://github.com/cue-lang/cue
json5 - JSON5 — JSON for Humans
libyaml-rust - LibYAML bindings for Rust