• Veraxus@kbin.social
    link
    fedilink
    arrow-up
    18
    ·
    1 year ago

    If you want the file to be directly human readable/editable:

    1. TOML
    2. YAML

    If you never need to look at it or edit it manually:

    1. JSON
    • vrighter@discuss.tchncs.de
      link
      fedilink
      English
      arrow-up
      14
      ·
      1 year ago

      I hate yaml with a passion. for stuff such as ansible it becomes an uneditable mess (one copy and paste away from destroying the whole file)

      luckily, yaml is a superset of json, so you could just write json and feed it through a yaml parser and it’ll work

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

          if i miss a quote in json, it’s an invalid file. I fix it and move on. Maybe just pass it through a beautifier or something.

          if I mess up indentation in yaml (which can easily happen after a copy and paste), I get a valid file that means something completely different. And no beautifier can help with that, because it’s a valid file. I have to look really closely to find the error, because tools can’t help. And when I do, I usually have to change multiple lines, instead of just adding a comma.

  • Streetdog@lemmy.world
    link
    fedilink
    English
    arrow-up
    17
    ·
    1 year ago

    TOML. Easy on the eyes and easy to grep and filter out comments.

    I really like the way Fail2Ban handles it with a .local config. The default doesn’t need to be backed up, and the .local is most minimal and concise. I’m unaware of any other programs doing it that way. I have scripts that either execute sed or tee -a to config files, after making a backup copy of the original.

    • abhibeckert@lemmy.world
      link
      fedilink
      English
      arrow-up
      15
      arrow-down
      1
      ·
      edit-2
      1 year ago

      Uh no, the worst is a tie between XML and JSON.

      XML because the syntax is hard to read and even harder to write, and JSON because you can’t do comments. WTF.

      • atzanteol@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        6
        arrow-down
        2
        ·
        1 year ago

        XML is a bit verbose but otherwise easy to understand. JSON5 supports comments.

        And neither requires me to explain weird formatting nuances to devops engineers.

        YAML is a pain to read (lists of structures are very messy), can’t be auto-formatted, and is full of weird “gotchas” (Norway, errant tabs, etc.) if you don’t do things “the right way.”

        Requiring the use of whitespace in formatting is wrong. End of.

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

            Oh, yeah, nothing like telling a dba they’re using the wrong editor when they’re trying to configure something.

            If your config format requires specific editors you’re using the wrong format.

      • jmanjones@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        1 year ago

        I instant exit on XML conf files. I have no idea how to parse the info, maybe I should. But there are too many tags and my eyes instantly glaze over when I see it!

      • Paradox@lemdro.id
        link
        fedilink
        English
        arrow-up
        5
        ·
        1 year ago

        Makes certain levels of nesting painful

        You can say this is a design choice, and you shouldn’t ever go too deep in config, and I’d agree, but it is a limiting factor to be aware of

  • exu@feditown.com
    link
    fedilink
    English
    arrow-up
    6
    ·
    1 year ago

    For simple stuff, INI is pretty good.

    I must admit I’ve written stuff that uses a JSON config file, but I might finish implementing YAML instead. Any day now…

    • Alien Surfer@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      1 year ago

      Agreed about INI for simple stuff. Not good for arrays and nested things though. Usually use binary for that type of config (with clear documentation). Most binary config files I use are plain old C structures. I’m not a web person so no need to make the config plain text.

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

    .el (Emacs Lisp), nothing beats using Lisp to configure a Lisp environment.

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

    Depends on the purpose of the software. In certain specific situations a plaintext *.txt is unbeatable.

      • Maharashtra@lemmy.world
        link
        fedilink
        English
        arrow-up
        5
        arrow-down
        3
        ·
        1 year ago

        The “PURPOSE” is the keyword.

        If the purpose of the software is to work in closed, offline environment with Mr. NOTECH operating it via “line 5: rotations per minute; line 6: temperature in Fahrenheit” commands, then trust me, it’s going to get the job done.

        • atzanteol@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          1 year ago

          “unbeatable” and “get the job done” are very different claims. If you just have bare unlabeled numbers on “magic lines” in a file - sure you can work with that. But I’d hardly say it’s “unbeatable” compared to “anything else” for readability and clarity. It’s the type of thing programming classes have students do so they don’t have to introduce libraries or other concepts.

          It’s very likely that Mr. NOTECH would be able to understand “TEMP_F: ###” just as easily as “put the temperature on line 6”. And it would likely be MUCH easier for Mr. NOTECH to look at a config file and read back to you what the temperature setting is. Especially if they haven’t worked with the software for long. As a bonus it would be easier for Mr. NOTECH to know whether the temperature should be in F or C. Or even Kelvin.

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

                I absolutely am. You’re simply overthinking it - the scenario I provided makes plaintext *.txt perfect.

                Sure, we can spend the rest of the day inventing scenarios, where Mr. NOTECH will be manipulated remotely by aliens, and what then, but that’s an exercise in creativity, not a situation that needs to be taken into account.

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

    For my last self-made program, I just wrote a config.py, and call import config from other code files and write my config in Python.

  • lnxtx@feddit.nl
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    1
    ·
    1 year ago

    That one which I can automate.

    I mainly use Ansible or Puppet. So YAML isn’t that bad if you fully understand it.

    Puppet language sux IMHO.

  • Andy@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    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.

  • Paradox@lemdro.id
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    I like how elixir approaches it: configs are just elixir script files that have a module for some common conventions. Gives you a lot of power, and no goofy new syntax

    • frezik@midwest.social
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      1
      ·
      1 year ago

      That works if you have a small, disciplined team. As the team grows and it becomes harder to enforce standards, config files that are run through the language compiler easily get filled with programming statements that shouldn’t be in a config file.