• kylian0087@lemmy.world
    link
    fedilink
    English
    arrow-up
    23
    arrow-down
    2
    ·
    1 year ago

    What is wrong with YAML for configuration? It is much more easy to read then say json.

    • brian@programming.dev
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 year ago

      There is some surprising behavior with some of the features of yaml, mostly arising from the fact that it looks nice to read. Here’s a list of things that you can avoid to avoid a lot of the pitfalls: https://hitchdev.com/strictyaml/why/ . I haven’t actually used strictyaml, but the arguments it presents are pretty solid and some are things I’ve run into in real environments

    • anyhow2503@lemmy.world
      link
      fedilink
      English
      arrow-up
      4
      arrow-down
      2
      ·
      1 year ago

      YAML is way too bloated of a standard and has a ton of inconsistencies between implementations, despite the widespread reputation of simplicity. It is easy to read as long as you limit yourself to a fraction of its capabilities and err on the side of caution when it comes to escaping characters (especially when number literals are involved, or booleans for that matter). As far as alternatives go, I prefer TOML for simple key=value configs, but it has its own issued and is nowhere near as featureful, for better or worse.

    • thevoiceofra@mander.xyz
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      2
      ·
      edit-2
      1 year ago

      If you’re just reading configs then yeah, it’s superior. If you’re maintaining big complex configurations, possibly for multiple machines, you need something to reduce boilerplate. Jsonnet, nickel or nix are excellent here. So the best way is to use one of those, generate yaml, and deploy. Saves you a lot of headaches but it’s one more moving thing in your pipeline which can break.