.yaml, .toml, etc?

  • pileghoff@programming.dev
    link
    fedilink
    arrow-up
    20
    ·
    1 year ago

    I usually use Json5. It’s JSON, but with all the weird quirks fixed (comments added, you can use hex numbers, you can have trailing commas etc.)

  • simonced@lemmy.one
    link
    fedilink
    English
    arrow-up
    16
    ·
    1 year ago

    A lot of good answers but I would add one note:

    • use a format that supports comments, and JSON is not one of those…
    • AeroLemming@lemm.ee
      link
      fedilink
      English
      arrow-up
      14
      arrow-down
      3
      ·
      1 year ago

      Of course it does!

      {
        comment: "This data is super important and it runs the system or something",
        data: ["Some", "stuff", "here"]
      }
      
        • AeroLemming@lemm.ee
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 year ago

          Please don’t actually do this. Comment stuff in the code and documentation, not the JSON.

          • sfera@beehaw.org
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            Don’t worry, I wouldn’t do things like this in JSON. Nevertheless, it can be very useful to have comments along with configuration values, for example to explain the actual values (not their purpose) and why they were chosen. That’s information you can’t add to the code which processes the values.

        • AeroLemming@lemm.ee
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          It’s so easy to use, and you can read the comments from in your program too!

          ^(in case you weren’t just playing along, please never do comments this way)

          • simonced@lemmy.one
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 year ago

            I liked the idea to be honest. I can just call the entry “description” instead and all is good ^^

            • AeroLemming@lemm.ee
              link
              fedilink
              English
              arrow-up
              2
              ·
              1 year ago

              Ideally, you would use TOML for human-readable configuration and document your JSON API with external documentation instead of sending comments around a bunch. If you need to display the description to the end user though, that would be a valid use case.

    • vrighter@discuss.tchncs.de
      link
      fedilink
      arrow-up
      2
      arrow-down
      1
      ·
      1 year ago

      json with comments can be parsed by a yaml parser. It’s how I write yaml, in fact (yaml is a superset of json. any valid json is valid yaml, but it also supports comments)

  • AverageCakeSlice@sh.itjust.works
    link
    fedilink
    arrow-up
    22
    arrow-down
    6
    ·
    1 year ago

    JSON by a mile. I hate the YAML plague, it’s some of the most unintuitive syntax I’ve seen and yet it’s everywhere in DevOps/SysOps.

    • Hexarei@programming.dev
      link
      fedilink
      arrow-up
      14
      arrow-down
      10
      ·
      1 year ago

      Yeah, any language in which whitespace count is semantically significant can go suck fat nards.

      • bignavy@programming.dev
        link
        fedilink
        English
        arrow-up
        9
        arrow-down
        1
        ·
        1 year ago

        Not sure whether fantastic troll or just no exposure to Python.

        Either way…I’m here for it.

        • Hexarei@programming.dev
          link
          fedilink
          arrow-up
          9
          arrow-down
          1
          ·
          1 year ago

          Neither, I’ve written plenty of Python and I know how useful it can be. However, as someone who is neurospicy, I find languages that have semantically l significant white space to be frustrating to read.

          Sure, there are tools to help with it. Sure, they help. But they don’t replace how much more useful curly braces are at defining scope.

          • bignavy@programming.dev
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 year ago

            You’re not wrong. Having to figure out which element is borked in a yaml file is not great. And the implementation using yaml is all over the place, so even though tools do exist, they’re mediocre at best.

            But, to be fair, Python has always done the same to me. As a fellow Neuro-spicy (and with a background in Java and C# and JavaScript), although the tools are better to point you in the right direction, significant white space (or indentations) are significant white space (or indentations).🤷‍♂️

    • kersplort@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      YAML works better with git than JSON, but so much config work is copy and pasting and YAML is horrible at that.

      Having something where changing one line doesn’t turn into changing three lines, but you could also copy it off a website would be great.

  • spartanatreyu@programming.dev
    link
    fedilink
    arrow-up
    14
    ·
    1 year ago

    It depends what you need your configuration file to be:

    Need a well defined easy to understand concrete configuration file?

    • Use .toml. It was made to be both human and computer friendly while taking special attention to avoid the pitfalls commonly found in other configuration files by explicitly stating expected types around commonly confused areas.

    Need a simple to implement configuration file?

    • Use .json. It’s famous for being so simple it’s creator “discoverer” could define it on a business card.

    Need an abstract configuration file for more complicated setups?

    • Use .ncl. Nickle allows you to define functions so that you can generate/compute the correct configuration by changing a few variables/flags.
    • Magnus Åhall@lemmy.ahall.se
      link
      fedilink
      arrow-up
      4
      arrow-down
      1
      ·
      1 year ago

      YAML here as well.

      Configuration many levels deep gets so much harder for me to read and write in JSON with all [], {} and “”

      Also the lack of comments… And YAML still is more used in software I’m using than JSON5, so I’d rather skip yet another format/library to keep track of.

    • argv_minus_one@beehaw.org
      link
      fedilink
      arrow-up
      4
      arrow-down
      2
      ·
      1 year ago

      Please do not use YAML. It’s a syntactic minefield. It also doesn’t allow tab indentation, which is supremely irritating.

      • Rikudou_Sage@lemmings.world
        link
        fedilink
        arrow-up
        3
        ·
        1 year ago

        As I said, I like it the most, so I will use it. I like its syntax (except for yes and no for booleans, but nothing’s perfect). I don’t care much for tabs vs spaces, I use tab in my IDE and whatever it does, it does.

  • vrkr@programming.dev
    link
    fedilink
    arrow-up
    9
    arrow-down
    1
    ·
    edit-2
    1 year ago

    No reason to go beyond simple key-value format like dotenv or just env variables. If you need more structure then maybe you are confusing configuration with state and this is not really the same thing.

  • Andy@programming.dev
    link
    fedilink
    arrow-up
    8
    ·
    1 year ago

    https://nestedtext.org/

    It’s like yaml but simple, consistent, untyped, and you never need to escape any characters, ever.

    Types and validation aren’t going to be great unless they’re in the actual code anyway.

    • timbuck2themoon@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 year ago

      Agreed.

      I honestly don’t understand anyone who likes json over it. Json is fine for certain things but manually typing that is pain ten times over. It’s better than XML surely but not by terribly much.

  • Edo78@feddit.it
    link
    fedilink
    arrow-up
    7
    arrow-down
    1
    ·
    1 year ago

    It really depends. I usually prefer json. It’s easily understandable from humans and from machines, it doesn’t depends on indentation and above everything else I like it very much 🤣

  • philm@programming.dev
    link
    fedilink
    arrow-up
    5
    ·
    edit-2
    1 year ago

    Depends on what you mean exactly with “file format”.

    If declarative functional programming falls under that, I think something like Nickel, the already mentioned Dhall or Nix. Though Nix more so for packaging and some kind of system management (NixOS?), it’s not easily embeddable into a runtime (your app?). Nickel or Dhall is better for that, as they are built from ground up with that in mind, Nickel is maybe the successor of Nix as it is inspired by Dhall and Nix (one goal is to use Nickel as frontend).

    The reason why I recommend a simple declarative language, is that they are IMHO much better composable as it lets the user hide boilerplate via functions. I almost always feel limited by static configuration formats like yaml, json etc…

      • philm@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        You might want to checkout NixOS (or home-manager if you don’t want a cold deep dive into a rabbit-hole).

        • Hexarei@programming.dev
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          You’re probably right I have checked it out, but so far home-manager was a bit of a cold shower to me. I had a ton of trouble wrapping my head around which parts of what config should be responsible for what - and lots of the documentation seems to either be out of date or relying on thing that are still in the ‘testing’ stage?

          I’m interested, but so far just found it frustrating.

          • philm@programming.dev
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            Hmm yeah it probably helps to be able to program functionally (it’s basically lambda calculus with lazy sets and a little bit of syntax sugar). NixOS has a little bit of a steeper learning curve. When understanding Nix itself and having a little bit dived into the the nixpkgs repo you’ll quickly get a grip for it (and understand some of the IMHO quirky design decisions).

            But then I feel it’s only going to get better, as the system can be perfectly configured to your liking and it stays like that across different machines etc. I think the initial investment has paid off for me so far. It’s really hackable and you can quickly try ideas without having to fear to break your system. Also something like nix flakes for good reproducible dependency management across different OS is really nice (at least if not much if any GUI is involved, then the different worlds (impure vs pure) sometimes clash together).