4 ms·
I'm puzzling over where I would use this sort of thing, over say Json, or simple xml, and I realise that it's mostly useful in cases where you're expected to ed
by bruce511 3y ago
I'm puzzling over where I would use this sort of thing, over say Json, or simple xml, and I realise that it's mostly useful in cases where you're expected to edit the configuration in a text editor.
That's not something I come across a lot - all my software (that I use) has a visual interface, and so raw editing of text/config files is not something we do.
So context really comes into play here. I can see how this would be very useful for some programs, and near useless for others. And more specifically useful for those who consume user-edited configuration files.
- zaebal 3y agoIt also reminds me the syntax of INI files.
- lexicality 3y agoCurious at to what technologies you work with? The work that I do and tools that I use have all manner of configuration file syntaxes and languages and a big headache for doing sysadmin work is trying to remember if a particular .rc file uses INI, YAML, JSON, TOML or some home rolled nonsense.
- Sujeto 3y agoI moved some config files from json to yaml. Maintaining the documentation became a lot easier, because before I had a document describing every config option, which I had to maintain separately, instead now I have comments in the config file itself.
- bonzini 3y agoNote that now you have "the Norway problem" instead. https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/ There's a whole spectrum of config formats including JSON, JSON5, strict YAML, YAML. It's quite messy.
- GuB-42 3y agoI found yaml to be surprisingly complex and tricky to write for how simple it looks. It is made to be beautiful and easy for a human to read, but the trade-off are a lot of implicit rules you need to be aware of.
- pydry 3y agoThe point of strictyaml is to fix that. The trade off is that you need to define a schema up front.
- riffraff 3y agoThe norway problem is not a problem if you use yaml 1.2. Which is 14 years old. EDIT: this sounded adversarial which was not my intention. Plenty of libraries do not support 1.2 which sucks, I just meant that it's something solved in theory a long time ago.
- debugnik 3y agoCould you explain further? The link contradicts this: > The most tragic aspect of this bug, however, is that it is intended behavior according to the YAML 1.2 specification. The real fix requires explicitly disregarding the spec - which is why most YAML parsers have it.
- detaro 3y agoThe link is wrong. YAML 1.2 fixed this.
- riffraff 3y agothe article is wrong, from what I can tell. From https://yaml.org/spec/1.2.2/ext/changes/ https://yaml.org/spec/1.2.2/ext/changes/ > Changes in version 1.2 (revision 1.2.0) (2009-07-21) > [...] > Only true and false strings are parsed as booleans (including True and TRUE); y, yes, on, and their negative counterparts are parsed as strings. Underlines _ cannot be used within numerical values.
- danielvaughn 3y agoI just started a new job where we’re writing a lot of Python, and I’m seeing TOML everywhere
- rob 3y agoAt work, we needed a config file for some employees to sit alongside a custom (non-web) script I wrote. These employees have zero technical knowledge (like, they wouldn't know basic HTML), and I found TOML to be pretty easy for them to understand. It looks like this: # config.toml [[podcasts]] title="Podcast 1" export_label="Label 1" [[podcasts]] title="Podcast 2" export_label="Label 2" It's flat for them, but gives me a nice `$podcasts` array of nested objects to work with and they don't need to worry about curly braces, indenting, etc. They can just copy/paste three lines if they need to "add" a new one. Of course, my use case is pretty simple and these are simple string values, but I found it pretty nice.