8 ms·
StrictYAML
- jitl 4y agoMy YAML secret weapon is that JSON is more or less valid YAML. So, if you want YAML with a “safer syntax”, just write JSON instead. You can sprinkle in comments if needed.
- pyrolistical 4y agoWith some caveats https://stackoverflow.com/a/44617419/21838 https://stackoverflow.com/a/44617419/21838
- Dylan16807 4y agoMost of which disappear with 1.2 Don't use YAML 1.1
- alexeldeib 4y agoFrom a sibling: json can’t have the header for yaml versions, so 1.2 arguably doesn’t solve this. If you force 1.2 without the header I suppose it works, but breaks compatibility?
- rurban 4y agoSo you get insecure YAML, in contrast to YAML 1.1. Don't use YAML 1.2, use the secure subset 1.1. Or even better StrictYAML
- Dylan16807 4y agoThe secure subset? I mean, things like "NO" were fixed later.
- rurban 4y agoYes, but objects, refs, tags came all in 1.2. StrictYAML got rid of all these, as all the safer YAML variants. E.g. perl5 still uses 1.0 for its cpan metadata abstraction, and still has to restrict these. I maintain the https://metacpan.org/pod/YAML::Safe https://metacpan.org/pod/YAML::Safe module, which allows whitelisting of certain objects.
- Ygg2 4y agoThere aren't many options for it. YAML spec is a huge with bunch of gotchas. E.g. C# has two listed parsers. One is 1.2 compatible and unmaintained.
- jmillikin 4y agohttps://john-millikin.com/json-is-not-a-yaml-subset https://john-millikin.com/json-is-not-a-yaml-subset
- GlitchMr 4y agoThis is an issue with Ruby's YAML implementation. YAML 1.2 processors should interpret documents without YAML directive as if they were YAML 1.2 documents - see https://yaml.org/spec/1.2.2/#681-yaml-directives https://yaml.org/spec/1.2.2/#681-yaml-directives.
- jmillikin 4y agoSee the last section -- a parser that interprets YAML as v1.2 by default will break for YAML v1.1 documents. There's no way to determine whether a `.yaml` file is YAML v1.1 or v1.2 without a version directive, and most YAML documents are v1.1 because most YAML parsers default to v1.1 semantics. I used Ruby as an example since it's easily available on most platforms, but you could also use Python or C++ or Swift or whatever language[1] you prefer. The underlying issue -- YAML not being a subset of JSON -- is universal. [1] Note that some libraries, such as go-yaml, do their own thing and don't conform to either v1.1 or v1.2 semantics.
- pyrolistical 4y agoMy favorite kind of strict yaml is just to say no.
- ainar-g 4y agoThere are basically two types of YAML file I've seen: 1. Application configuration. That would be better off as environment variables and/or JSON(5) for structured data. 2. CI/CD configuration. Those should really be scripts, because basically every such configuration file I've seen invents its own way of making conditionals anyway.
- woojoo666 4y agoMost docker compose files I've seen are not complex enough to warrant scripting, but look way better as YAML than JSON. In those cases I think StrictYaml would be a great fit. Also scripts are very different from configs. Configs are declarative, (most) scripts are imperative. If your config is complex enough then maybe you should move some logic into imperative code, but you can still have a config on top of that.
- kaichanvong 4y agoI like XML or the no. Going off to do something, entirely non-computer based could be nice. further onwards from that you might have a nice chat in one of those hidden inter-racial dimensional pubs with neither futuristic or westworld themes.
- smcl 4y agoWhat on earth does this mean
- jeroenhd 4y agoHaving used yaml for anything from configuration to Gitlab CI pipelines, I can't see how JSON could possibly improve the situation. It's an ugly subset of YAML more readable by computers at the expense of being readable by humans. Yes, if you want, you can write some terrible YAML. It's your project though, you don't need to make your YAML terrible. The same is true for everything else about your configuration, code, and infrastructure. I've seen some terrible JSON configuration that used the fact that some JSON parsers will overwrite subsequent reuses of keys as a method of documentation, for example. I know that in YAML 1.2 you can just enter JSON into a YAML file and it'll work if that's what you want. I haven't found a real life example of why that would be better, though. If you're going configuration format purist, use XML. It's actually good at requiring you to follow the schema and there are XML parsers for absolutely any platform. You can write conditions in an accompanying XSLT file for "active" configuration.
- Dylan16807 4y agoSo the documentation talks about the problem of 「null」being confused with 「"null"」. But the solution is to make it impossible to write 「null」 at all? I don't think I would have suggested that one...
- benibela 4y agoSimple solution: Make it impossible to write 「"null"」
- hombre_fatal 4y agoIt shows on the docs how to decode ‘a: null’ with the schema so I’m missing the part where you can’t use null.
- Dylan16807 4y agoOh I think I found the page you mean? https://hitchdev.com/strictyaml/using/alpha/scalar/empty/ https://hitchdev.com/strictyaml/using/alpha/scalar/empty/ It looks like you need to use an empty string and you can tell it to translate to None. That's better than nothing, but it's still basically an inability to use actual null here.
- hombre_fatal 4y agoI think I'm misunderstanding you, but StrictYAML's biggest departure from YAML is that it doesn't try to guess types at all. Everything is decoded as a string by default until you specify otherwise with its schema system. Here you can use `NullNone` to parse `null` into None. from strictyaml import Map, NullNone, Int, load schema = Map({"a": NullNone() | Int()}) load("a: null", schema) == {"a": None} load("a: 7777", schema) == {"a": 7777}
- Dylan16807 4y agoIt doesn't guess, but also the data can't tell it. It's not just that you get a string by default, it's that everything starts as a string and then goes through post-processing. If you want to distinguish between 'any string' and 'not a string', you can't. > Here you can use `NullNone` to parse `null` into None. That's the worst possible outcome for poor Christopher Null. The best you can do for him is use "a:" to mean null but at that point you're not really dealing with nulls, you've just gone with strings and used an empty string.
- Kab1r 4y agoThe need for StrictYAML makes me realize how unnecessarily complex YAML is. I think choosing to make YAML a superset of JSON was a smart idea to encourage adoption, but as YAML has grown in popularity it has outgrown the feature. It reminds me that there a constant tradeoff—between legacy comparability and simplicity—that applies beyond configuration formats.
- deleted 4y ago[deleted]
- HelloNurse 4y agoSince JSON is already terrible on its own, making YAML a superset of JSON is a great example both of "putting lipstick on a pig" and of considering "it works in the common case, let's try something even harder" an acceptable design standard.
- d12bb 4y agoMy biggest gripe with YAML is significant whitespace and the inability to use tabs for indenting, so still a No for me.
- js8 4y agoIt's a mystery to me why people won't start using properly designed configuration languages, like Dhall (https://dhall-lang.org/ https://dhall-lang.org/) or Cue (https://cuelang.org/ https://cuelang.org/). Even using csexps (https://en.wikipedia.org/wiki/Canonical_S-expressions https://en.wikipedia.org/wiki/Canonical_S-expressions) would be progress.
- andybak 4y agoDepends who the intended audience is. I wouldn't inflict curly braces on anyone other than software developers and certainly not where you expect people to do a lot of manual data entry. Even I tend to write "pseudo-YAML" and then add the JSON line noise programmatically if I'm entering a lot of data.
- Ygg2 4y agoI wouldn't inflict YAML on anyone either. - Oh you used a tab instead of a space. - What do you mean country code can be 'no'? - Sure we are JSON compatible**! - Yeah. 1e3 is an actual string. If it's not. We're not compatible with YAML 1.1 - Yes. I will import your remote exploit.
- oreilles 4y ago> Dhall is a programmable configuration language that you can think of as: JSON + functions + types + imports So like, Typescript but worse ?
- HelloNurse 4y agoMore along the lines of Haskell but Javascript.
- technion 4y agoGithub actions is the one that surprised me. It's a recent enough invention that it was built long after all these discussions, issues raised, and alternatives proposed. I've had far more issues getting these YAML files correctly formatted than I should admit, and every test means pushing a commit and waiting to see what happens.
- twarge 4y ago“Ability to read in YAML, make changes and write it out again with comments preserved.” How are the comments preserved in the Python representation? Is it some kind of ordered dict?
- andreareina 4y agoProbably the Map() class actually takes a series of nodes, that could either be comment or a key/value pair (and validates that you don't have duplicate keys). tomlkit does something similar.
- danjc 4y agoTangential but before I get to validating YAML I’d really appreciate recommendations on a decent JavaScript YAML parser/serializer.
- shaicoleman 4y agoStrictYAML removes features that might be useful for some usecases, such as Node anchors+Refs and Flow Style. I don't think the cost of an additional standard is worth it in this case. While YAML has issues, they aren't much of problem if you use a linter, such as yamllint [1]. This can be enforced as part of the CI process. 1. https://github.com/adrienverge/yamllint https://github.com/adrienverge/yamllint
- bvrmn 4y agoSchema requirement is very daunting part of StrictYAML. Basic types besides string are useful.
- ewuhic 4y agoWhat was the name of that serialization language “for humans” featured on hn recently as someone's long-going personal project?
- BiteCode_dev 4y agoXKCD 927, once again. I would rather avoid YAML all together. Small human editable files: TOML. Big machine editable files: JSON. And I validate all that with pydantic. I wish CUElang was ready for prime time, that would solve all this at once.
- deleted 4y ago[deleted]
- 0x69420 4y agoon the front page right now: - a git explainer centered around git internals, serving as an indictment of git's ux - a parser for a restricted subset of yaml, serving as an indictment of yaml's excesses on the front page yesterday: - an rsync explainer centered around rsync internals, where part 1 details how rsync is wrapped in a dockerfile and a perl script in order to be made useful - a sad thinkpiece on how baroque the web has become on the front page the day before: - a go utility weighing in at tens of source files that implements what should be a built-in feature of AWS - an article on encapsulation in rust, the buried lede of which is "you must audit your transitive dependency graph in order to retain the benefits of rust" why do so many technologies feel like self-harm?
- kriz9 4y agoExploration? Who knows, maybe we will all replace our yaml with perl at some point. Maybe not. But it is definitely good to see these somewhat crazy experimentations. That is how we move forward.
- brigandish 4y agoPossibly it's because it's hard to get things right the first time, but sometimes it's better than the old way so there's a big shift to it, and once we know a better way it's hard to shift people to the better thing because the old thing was just good enough. Come to think of it, this probably applies to any product.
- rexpop 4y agoI don't understand what, in your perspective, would be the most convivial technology. Please elucidate?
- HelloNurse 4y agoConvivial technology consists of tools to eat and drink: knives, chopsticks, crustacean access instruments, sporks, sushi conveyor belt systems... Did you mean something else?
- 4y ago
- bschwindHN 4y agoMaking my obligatory comment that JSON5 is a sane alternative to YAML. Better than TOML too for more deeply nested structures.
- vsajip 4y agoI developed a configuration format which is similar to, and a superset of, the JSON format. It's not new - it dates from well before its first announcement in 2008 - and has the following aims: * Allow a hierarchical configuration scheme with support for key-value mappings and lists. * Support cross-references between one part of the configuration and another. * Provide a string interpolation facility to easily build up configuration values from other configuration values. * Provide the ability to compose configurations (using include and merge facilities). * Provide the ability to access real application objects safely, where supported by the platform. * Be completely declarative. It's similar to newer formats such as JSON5, HJSON, HOCON and similar but offers a number of features [0] which they don't, as indicated by the above list. It's not intended to occupy the niche where you find things like Cue, Jsonnet, Dhall and similar. It was just never especially publicised when first implemented for use in Python projects, but it now also has implementations for the JVM, .NET, Go, Rust, D, JavaScript [1], Ruby and Elixir (all BSD-3-Clause licensed) and it would be great to get feedback on the project from the HN community. [0]: https://docs.red-dove.com/cfg/intro.html https://docs.red-dove.com/cfg/intro.html - description of features and comparison with other similar systems [1]: https://docs.red-dove.com/cfg/playground.html https://docs.red-dove.com/cfg/playground.html - uses the JS implementation to create an interactive playground
- rubatuga 4y agoI’m hoping NestedText will take the place of YAML: https://nestedtext.org/en/stable/ https://nestedtext.org/en/stable/
- mixmastamyk 4y agoStrict yaml works well and avoids many common problems. I recommend it for most uses of yaml and quite a few others.
- adontz 4y agoLast few years I was playing with configuration files and my final thought was always, why not to have a Python module imported for configuration just like Django does? Sometimes I need to substitute variables. Sometimes I need to generate similar blocks from templates. Sometimes I need to read part of configuration from environment variable. Simply importing Python module was always easier.
- mixmastamyk 4y agoIt works quite well until you need a non-developer to change it. Or not using Python, or multiple technologies.
- adontz 4y agoSo you believe there are engineers who can edit YAML, but cannot edit Python? Terraform introduced a brand new language, Pulumi uses JavaScript. strictyaml website has examples in Python, that's why Python.
- mixmastamyk 4y agonon-developer
- adontz 4y agoWho are these non developers who can edit YAML but not Python?
- mixmastamyk 4y agoEveryone. They might be able to handle foo = "bar", but some will not be able to handle the quotes, or understand the difference between 123 or "123". If you use anything else from Python lang they drop like flies. def? loop? Out of the question. I've even seen so-called IT people not able to handle scripting. .ini files are about the only thing you can count on, (almost) guaranteed that a non-developer can handle.
- nathants 4y agothis is a good idea, but difficult to nail in scope and multi-lang support. i’ve made similar attempts[1,2]. tbh if this had go support i’d probably try it today. json, yaml et al are ways to declare literal data. this is good. they are fine. the issues always come from what the data is used for. nailing your schema, making your data structures as simple as they can be and no simpler, this is where the engineering happens. this is the hard part. literally all that matters. not validating arbitrary data inputs is obviously a bad idea. whether you validate them via a high level library or tediously by hand[3] isn’t very important. what is important is that the data structures are sane, simple, and stable. if they are easy to describe, they might be a good idea. if the approach the complexity of general purpose pl, they probably aren’t. most literal data schemas are too broadly scoped. too general. github actions, other ci, k8s, etc. they have too many knobs, too many permutations. this is not a feature, it is a failure of design. good schema validation won’t fix broken design. it’s unrelated. 1. https://github.com/nathants/py-schema https://github.com/nathants/py-schema 2. https://github.com/nathants/clj-schema https://github.com/nathants/clj-schema 3. https://github.com/nathants/libaws/blob/ae48040911bf2c0554da5e8da99ee8a145581698/lib/infra.go#L2515 https://github.com/nathants/libaws/blob/ae48040911bf2c0554da...
- nrvn 4y agoI believe YAML has deserved the motto: "Everyone hates YAML. Everyone writes a lot of YAML."