12 ms·

Toml has some hairy bits. Lists of objects, lists of lists of objects, objects of lists of objects. Complex objects with top level fields...

chillfox 5y ago
Yep, Although I do feel like there is a case to be made that if you need a Turing complete configuration language then in most cases you failed your users by pushing too many decisions on to them instead of deciding on sensible defaults. And if you are dealing with one of the rare cases where Turing complete configuration is desirable then maybe use Lua or something like that instead.
- pc86 5y ago
  Even if you have sensible defaults don't you still need to be able to parse configured changes?
  - chillfox 5y ago
    Not always, sometimes all other options are just wrong. Or you can auto detect the correct setting.
- dnautics 5y ago
  I'm not defending YAML. YAML is terrible. It's even worse with logic and/or templates (looking at you, Ansible). Toml is certainly better but I'm still baffled as to why we don't have a "better YAML". YAML could almost be okay.
  - vitiral 5y ago
    I'm curious what your thoughts are on a config language I'm working on. GitHub.com/vitiral/zoa It has both binary and textual representation (with the first byte being able to distinguish them), and the syntax is clean enough I'm planning on extending it into a markup language as well.
  - chillfox 5y ago
    Yeah, I think it's because nobody sat down and methodically created it. People create config languages that work for their use case and then it is just a happy accident if it works for other things. I don't think anyone has put serous effort into designing a configuration language. And by that I mean collect use cases, study how other config languages does things, make drafts, and test them. etc...
    - svieira 5y ago
      Dhall and Cue come to mind as ones that _feel_ more designed https://github.com/dhall-lang/dhall-lang https://github.com/dhall-lang/dhall-lang https://cuelang.org/docs/usecases/configuration/ https://cuelang.org/docs/usecases/configuration/
      - chillfox 5y ago
        Interesting... Me, the programmer finds those kinda cool. And the sysadmin in me developed a dislike of both within 1 minute of looking at them. Honestly, I think a good configuration library should be more than a spec, it should come with a library that handles parsing/validation. See, there are two sides to configuration, the user and the program. Knowledge about the values, defaults and types should live on the program side and should be documented. Then the user side of configuration can be clean and easy to read/write and most important of all, allow the user to accomplish the most common configuration without having to learn a new config language on top of learning the application.
        BiteCode_dev 5y ago
        > Honestly, I think a good configuration library should be more than a spec, it should come with a library that handles parsing/validation You just described CUELang. The type system allows to define a schema as well as the data, in the same file, or in 2 separate ones. Then you can call either a cli tool (that works on linux, windows or mac) or use the Go lib (or bind to it). For compat, cue can import and export to yaml, json and protobuf, as well as validate them.
  - nerdponx 5y ago
    There's also Lua, which is a full Turing complete language but is still pretty nice for writing config files, and is easy to embed.
    - nerdponx 5y ago
      Followup to my own post: don't forget about Scheme! Same nice properties as Lua, but you get some extra conveniences from using s-expressions (which can represent objects somewhat more flexibly, like XML, than Lua, which is more or less 1:1 with JSON).
  - chillfox 5y ago
    About Ansible, I think it gained it's success partially due to YAML. Ansible is worse than Puppet and CFEngine in many ways, but it is superior in the user interface. It managed to not only be a config management solution, but provide a universal config language that most apps could be configured with. So for a lot of use cases, if you know Anisible/YAML then you don't have to learn a new configuration language on top of learning a new application.
    - dnautics 5y ago
      The problem with Ansible is it's not universal, because most app playbooks, are configured in the worst possible way. In my experience typically you get handed an Ansible script, something which you'd hoped was declarative but isn't (like a version that apt-get grabs isn't fixed, or even, gets patched) then suddenly a downstream templated command fucks up, and the person who wrote the script isn't around anymore (or you don't trust their chops because they are a blowhard that worked at Google/Facebook and had a coddling ops team behind them in the past) or worse it's from "community" and has a billion hidden settings that you can't be bothered to grok - and so you have to dig so many layers down that you are better off just fucking rewriting the Ansible script to do the one thing which probably should have been four lines. In any case, I found Ansible scripts to have like a 3 month half life. If we were lucky. I'm not bitter.
      - chillfox 5y ago
        haha, I can go on lengthy rants about every single configuration management system that I have used. My dream configuration system should revert to default when the config is removed (keeping data). Have a simple/easy user interface. Have maintained modules with sane defaults for the 500 most common server software. I would rather there be no module than an abandoned one with unsafe defaults, that way it is clear that I would have to maintain my own if I want to use that particular piece of software. Performant, it really shouldn't take more than a few minutes to apply a config change. No more than 30 min for initial run.
    - Steltek 5y ago
      Early on, Ansible was primarily agent-less from the start which made it ridiculously easy to sneak into existing infrastructure and manual workflows. I probably would not have been able to stand up Puppet or Salt or whatever but I could run Ansible all by myself with no one to stop me :).
  - brigandish 5y ago
    There's StrictYAML[1][2]. Can't say I've used it as let's face it, most projects bind themselves to a config language - whether that be YAML, JSON, HCL or whatever - but I'd like to. [1] https://hitchdev.com/strictyaml/ https://hitchdev.com/strictyaml/ [2] https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml
addaon 5y ago
... lack of a hex float representation ...
mikepurvis 5y ago
I understand the pragmatic reasons for it being the way it is, but I still wish TOML didn't require all strings to be quoted.
ryukoposting 5y ago
This is why I like INI. It doesn't have these problems, because it doesn't try to wrangle the notion of nested objects (or lists) in the first place. The lack of a formal spec is a problem, sure, but it such a basic format that it's kind of self-explanatory.
- Dylan16807 5y ago
  When the problem is TOML not supporting easy nesting, a solution of "Don't nest." works just as well in TOML as it does in ini. It's not really an advantage of ini. Especially when a big factor in TOML not making it easy is that TOML uses the same kind of [section]\nkey=value formatting that ini does!
- BiteCode_dev 5y ago
  You can use toml as a better ini by limiting yourself to the key / value schema. It still superior because: - it has a spec - it has other types than strings - you can always decide you actually need nested data, and add them later
  - withinboredom 5y ago
    > it has other types than strings But isn't the config file just a string?
    - chipsa 5y ago
      Everything gets serialized to a string of bytes. The point is that you can fail at parsing when the value doesn't make sense, rather than failing at some point in the future when you decide to use the value and it doesn't make sense. And if you have a defined schema, you can have your editor validate it against the schema when saving, so you don't accidentally have "FILENOTFOUND" in a Boolean.
  - ryukoposting 5y ago
    I wrote an INI parser that has numerical, boolean, timestamp, MAC address, and IP address types ;) "advantages" of not having a spec! Seriously: for application-specific config files, the lack of a formal spec can be kind of a nice thing. You can design your parser to the exact needs of your program, with data types that makes sense for your use case. Throw together a formal grammar for use in regression testing, and you're all set. Obviously a formal spec is essential for data interchange, but that's why JSON exists. To me, YAML is in a gray area that doesn't need to exist. The same thing goes for TOML, but to a far lesser extent.

chillfox 5y ago

Yep, Although I do feel like there is a case to be made that if you need a Turing complete configuration language then in most cases you failed your users by pushing too many decisions on to them instead of deciding on sensible defaults. And if you are dealing with one of the rare cases where Turing complete configuration is desirable then maybe use Lua or something like that instead.

pc86 5y ago
Even if you have sensible defaults don't you still need to be able to parse configured changes?
- chillfox 5y ago
  Not always, sometimes all other options are just wrong. Or you can auto detect the correct setting.
dnautics 5y ago
I'm not defending YAML. YAML is terrible. It's even worse with logic and/or templates (looking at you, Ansible). Toml is certainly better but I'm still baffled as to why we don't have a "better YAML". YAML could almost be okay.
- vitiral 5y ago
  I'm curious what your thoughts are on a config language I'm working on. GitHub.com/vitiral/zoa It has both binary and textual representation (with the first byte being able to distinguish them), and the syntax is clean enough I'm planning on extending it into a markup language as well.
- chillfox 5y ago
  Yeah, I think it's because nobody sat down and methodically created it. People create config languages that work for their use case and then it is just a happy accident if it works for other things. I don't think anyone has put serous effort into designing a configuration language. And by that I mean collect use cases, study how other config languages does things, make drafts, and test them. etc...
  - svieira 5y ago
    Dhall and Cue come to mind as ones that _feel_ more designed https://github.com/dhall-lang/dhall-lang https://github.com/dhall-lang/dhall-lang https://cuelang.org/docs/usecases/configuration/ https://cuelang.org/docs/usecases/configuration/
    - chillfox 5y ago
      Interesting... Me, the programmer finds those kinda cool. And the sysadmin in me developed a dislike of both within 1 minute of looking at them. Honestly, I think a good configuration library should be more than a spec, it should come with a library that handles parsing/validation. See, there are two sides to configuration, the user and the program. Knowledge about the values, defaults and types should live on the program side and should be documented. Then the user side of configuration can be clean and easy to read/write and most important of all, allow the user to accomplish the most common configuration without having to learn a new config language on top of learning the application.
      - BiteCode_dev 5y ago
        > Honestly, I think a good configuration library should be more than a spec, it should come with a library that handles parsing/validation You just described CUELang. The type system allows to define a schema as well as the data, in the same file, or in 2 separate ones. Then you can call either a cli tool (that works on linux, windows or mac) or use the Go lib (or bind to it). For compat, cue can import and export to yaml, json and protobuf, as well as validate them.
- nerdponx 5y ago
  There's also Lua, which is a full Turing complete language but is still pretty nice for writing config files, and is easy to embed.
  - nerdponx 5y ago
    Followup to my own post: don't forget about Scheme! Same nice properties as Lua, but you get some extra conveniences from using s-expressions (which can represent objects somewhat more flexibly, like XML, than Lua, which is more or less 1:1 with JSON).
- chillfox 5y ago
  About Ansible, I think it gained it's success partially due to YAML. Ansible is worse than Puppet and CFEngine in many ways, but it is superior in the user interface. It managed to not only be a config management solution, but provide a universal config language that most apps could be configured with. So for a lot of use cases, if you know Anisible/YAML then you don't have to learn a new configuration language on top of learning a new application.
  - dnautics 5y ago
    The problem with Ansible is it's not universal, because most app playbooks, are configured in the worst possible way. In my experience typically you get handed an Ansible script, something which you'd hoped was declarative but isn't (like a version that apt-get grabs isn't fixed, or even, gets patched) then suddenly a downstream templated command fucks up, and the person who wrote the script isn't around anymore (or you don't trust their chops because they are a blowhard that worked at Google/Facebook and had a coddling ops team behind them in the past) or worse it's from "community" and has a billion hidden settings that you can't be bothered to grok - and so you have to dig so many layers down that you are better off just fucking rewriting the Ansible script to do the one thing which probably should have been four lines. In any case, I found Ansible scripts to have like a 3 month half life. If we were lucky. I'm not bitter.
    - chillfox 5y ago
      haha, I can go on lengthy rants about every single configuration management system that I have used. My dream configuration system should revert to default when the config is removed (keeping data). Have a simple/easy user interface. Have maintained modules with sane defaults for the 500 most common server software. I would rather there be no module than an abandoned one with unsafe defaults, that way it is clear that I would have to maintain my own if I want to use that particular piece of software. Performant, it really shouldn't take more than a few minutes to apply a config change. No more than 30 min for initial run.
  - Steltek 5y ago
    Early on, Ansible was primarily agent-less from the start which made it ridiculously easy to sneak into existing infrastructure and manual workflows. I probably would not have been able to stand up Puppet or Salt or whatever but I could run Ansible all by myself with no one to stop me :).
- brigandish 5y ago
  There's StrictYAML[1][2]. Can't say I've used it as let's face it, most projects bind themselves to a config language - whether that be YAML, JSON, HCL or whatever - but I'd like to. [1] https://hitchdev.com/strictyaml/ https://hitchdev.com/strictyaml/ [2] https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml

addaon 5y ago

... lack of a hex float representation ...

mikepurvis 5y ago

I understand the pragmatic reasons for it being the way it is, but I still wish TOML didn't require all strings to be quoted.

ryukoposting 5y ago

This is why I like INI. It doesn't have these problems, because it doesn't try to wrangle the notion of nested objects (or lists) in the first place. The lack of a formal spec is a problem, sure, but it such a basic format that it's kind of self-explanatory.

Dylan16807 5y ago
When the problem is TOML not supporting easy nesting, a solution of "Don't nest." works just as well in TOML as it does in ini. It's not really an advantage of ini. Especially when a big factor in TOML not making it easy is that TOML uses the same kind of [section]\nkey=value formatting that ini does!
BiteCode_dev 5y ago
You can use toml as a better ini by limiting yourself to the key / value schema. It still superior because: - it has a spec - it has other types than strings - you can always decide you actually need nested data, and add them later
- withinboredom 5y ago
  > it has other types than strings But isn't the config file just a string?
  - chipsa 5y ago
    Everything gets serialized to a string of bytes. The point is that you can fail at parsing when the value doesn't make sense, rather than failing at some point in the future when you decide to use the value and it doesn't make sense. And if you have a defined schema, you can have your editor validate it against the schema when saving, so you don't accidentally have "FILENOTFOUND" in a Boolean.
- ryukoposting 5y ago
  I wrote an INI parser that has numerical, boolean, timestamp, MAC address, and IP address types ;) "advantages" of not having a spec! Seriously: for application-specific config files, the lack of a formal spec can be kind of a nice thing. You can design your parser to the exact needs of your program, with data types that makes sense for your use case. Throw together a formal grammar for use in regression testing, and you're all set. Obviously a formal spec is essential for data interchange, but that's why JSON exists. To me, YAML is in a gray area that doesn't need to exist. The same thing goes for TOML, but to a far lesser extent.