As much as I am an old-school Unix zealot, I think it is time to move towards a well standardised binary config format with non-trivial types (i.e a schema). There still has to be a standard text format, but only for the source from which the live configs have to be built. Done right, this has several advantages: 1. Built-time validation (or at least type checking). 2. Built configs can be easy to parse but (potentia…
YAML: Probably not so great after all
241–250 of 457 posts
Re: YAML: Probably not so great after all
#242Earlier quoted context omitted.
Why not use a “stream” of objects? {"cmd": "git checkout", "when": 1234} {"cmd": "vagrant up", "when": 4567} Not sure about other languages and libraries, but Go supports this out of the box[1]. And while we're at it, why not CSV? That can be processed with awk. #cmd,when "git checkout","1234" "vagrant up","4567" [1]: https://play.golang.org/p/sTN9z4Kv3DB
CSV is fine for simple cases but has issues with versioning (adding new/optional fields) and nested data like arrays. The object stream idea is apparently supported widely and seems pretty strong. Thanks for the suggestion!
Have you considered SQLite? I know it’s not a friendly text format, but it alleviates a lot of the issues with the “append to a text file” approach, such as concurrency. It’s great for this sort of thing.
Re: YAML: Probably not so great after all
#243Earlier quoted context omitted.
Aren't we just reinventing the wheel, though? Got your structured data format, now you need parsers (tons available for XML, incl SAX, DOM parsers, SimpleXML, Nokogiri...) a schema and validation tools (XSD), a templating mechanism (XSLT), a query language (XPath), ... JSON was a reaction to the verbosity of XML, but a better reaction would have been to work harder on our text editors so that working with XML would b…
> JSON was a reaction to the verbosity of XML, but a better reaction would have been to work harder on our text editors so that working with XML would be just as easy as working with JSON in terms of the numbers of keystrokes needed. Isn't that only solving half the problem? XML is also pretty difficult to read
I’d say this is schema-dependent. If you’re talking about plist files, sure; those are ugly and unintuitive. But on the whole I find XML far easier to read than JSON. With closing tags, what you lose in terseness is made up for with scannability: it’s easier to understand the document hierarchy at a glance, and find your place again after editing. Whereas with JSON I often have to match curly braces in my head, or add comments like `// /foo` which isn’t even possible outside of JS proper or a lax-parser environment.
Re: YAML: Probably not so great after all
#244fish shell is looking for a new text serialization format for its history file (currently it uses an ad-hoc broken psuedo-YAML). Boxes to check: 1. Self describing format 2. SAX-style parser available to C++ 3. Easy for users to understand and ad-hoc parse using command-line tools 4. No document closing necessary, so appending is trivial YAML looks pretty good: - cmd: git checkout file.txt when: 1565133286 pwd: /home…
Disclaimer: I work on Tree Notation. ( https://github.com/treenotation/jtree ) Here's a proposal: use a Tree Language. I created a demo for you called "Fished": https://github.com/breck7/fished . Took me just a few minutes but already get type check, autocomplete, syntax highlighting, and more. Tree Notation is early, and there will be kinks until the community is bigger, but I think it may be useful for you. http://…
Re: YAML: Probably not so great after all
#245Despite spending time writing and reading YAML on a daily basis for years, it still trips me up once things get non-trivial. It's definitely my least-favorite non-propritery config file format. XML might be overly verbose, but there are no surprises (unless you go bananas with schemas).
Yeah. I never got the hate for XML. I feel like it was always mismatched expectations: some people wanted something the Markdown of configuration files, and other people wanted something extensible enough to encode any possible data structures.
Not to talk about the attribute/content duality and all the ill-defined parsers it leads to.
Re: YAML: Probably not so great after all
#246From my experience, while YAML itself is something one can learn to live with, the true horror starts when people start using text template engines to generate YAML. Like it's done in Helm charts, for example, https://github.com/helm/charts/blob/master/stable/grafana/te... Aren't these "indent" filters beautiful?
I'm pretty much thinking I want Go as a pre-config where I can set variables, loops, and conditionals and that my editor can help with auto-complete. Maybe I can "import github.com/$org/helmconfig" and in the end write one or more files for config.
Re: YAML: Probably not so great after all
#247So what's the HN consensus on the best format for config files? Is it TOML as the author seems to prefer at the end?
It's telling that the responses to this question are broad and varied. Still not a well solved problem, it seems.
Re: YAML: Probably not so great after all
#248From my experience, while YAML itself is something one can learn to live with, the true horror starts when people start using text template engines to generate YAML. Like it's done in Helm charts, for example, https://github.com/helm/charts/blob/master/stable/grafana/te... Aren't these "indent" filters beautiful?
I think it all depends. Most of the time I would agree that you shouldn't template yaml, but sometimes, it's the lesser of two evils.
Re: YAML: Probably not so great after all
#249Yaml is great at the core. It just has too many features, the first things I disable. A simplified subset, .syml would be a good idea.
StrictYAML[0] is a YAML subset that removes some of the problematic features. The implementation is in Python. [0] https://github.com/crdoconnor/strictyaml
Re: YAML: Probably not so great after all
#250From my experience, while YAML itself is something one can learn to live with, the true horror starts when people start using text template engines to generate YAML. Like it's done in Helm charts, for example, https://github.com/helm/charts/blob/master/stable/grafana/te... Aren't these "indent" filters beautiful?
k8s and helm is where I learned to dislike yaml. I now want a compiled and type safe language that generates whatever config a system needs. I'm pretty much thinking I want Go as a pre-config where I can set variables, loops, and conditionals and that my editor can help with auto-complete. Maybe I can "import github.com/$org/helmconfig" and in the end write one or more files for config.