371–380 of 412 posts
JSON + comments + trailing commas + naked keys + multiline strings would be a great alternative. Maybe something like JSON5.
Have you considered Lua tables? The syntax resembles JSON, but simpler, and keys don't need to be quoted. Trailing commas are allowed, and so are multiline strings.
Earlier quoted context omitted.
Is there an implementation of strict yaml that you know of for Ruby?
If you are writing a new YAML implementation, then yeah, you want a simpler spec to follow. If on the other hand you are using a YAML library... I've had pretty good success using YAML compatibly across Python, Ruby, C# and Go projects. Do you have a particular issue in mind that the existing Ruby implementation doesn't address?
Earlier quoted context omitted.
In contrast, JSON is super intuitive and basically self documenting. Personally I've found the exact opposite when dealing with 'normal' people. Most people can get basic YAML, but unless they're a programmers (or at least know how to program) most people fail miserably at writing JSON by hand.
See how much fun these people have trying to figure out why their application crashes because they put a tab instead of spaces into the YAML file.
Also detects repeated hash keys. This is a very good compromise between user-friendliness and machine-friendly specification and serialization.
Thank you very much for YAML! It is a critical user-interceptable interchange mechanism at several companies that I have worked at.
Earlier quoted context omitted.
You don't know when you'll need to generate or parse your config files with something that either can't read, write or execute your language. Django's settings.py sucks. I've used Django since the 0.9 days. It's extremely impractical and needs to be worked around constantly.
Settings.py is uniquely bad, though, IMO because it tries to be a badly defined dict(), instead of exposing proper configuration interfaces. Ruby config files are common and usually fairly great, see for example the Vagrantfiles. And you won't have to generate your config files (parsing, maaaaaybe), because those needs are covered by the fact that the files are programs. They are _already_ generating a configuration.
Yes, theoretically, if settings.py was a "generator" format that you ran as a pre-step (like you do to get parser-generators like Bison to spit out source files for you to work with), and this generator actually spat out something like a settings.json, and all the rest of the infrastructure actually dealt with the settings.json rather than the generator, then, yes, it wouldn't matter. Tools in other languages could just generate the settings.json directly.
As it stands, none of those things are true, so tools in other languages actually need to do something that outputs settings.py files.
Earlier quoted context omitted.
Settings.py is uniquely bad, though, IMO because it tries to be a badly defined dict(), instead of exposing proper configuration interfaces. Ruby config files are common and usually fairly great, see for example the Vagrantfiles. And you won't have to generate your config files (parsing, maaaaaybe), because those needs are covered by the fact that the files are programs. They are _already_ generating a configuration.
> And you won't have to generate your config files (parsing, maaaaaybe), because those needs are covered by the fact that the files are programs. They are _already_ generating a configuration. Yes, theoretically, if settings.py was a "generator" format that you ran as a pre-step (like you do to get parser-generators like Bison to spit out source files for you to work with), and this generator actually spat out someth…
That means that if I wanted to configure Vagrant with JSON, there is no force in the universe that could stop me.
If the config file is actually a normal program, then it can do normal program things, then any benefit from using JSON instead is nullified by the fact that you can still use JSON. In turn, if your tools primary configuration is via a more limited settings, you're stuck with it. Not even "generators in other languages" allow comparable runtime flexibility.
Earlier quoted context omitted.
If you're making comments for yourself in config files you control: /\/\/.*/gm https://regexr.com/3rbgb
"hello // syntax error"
My point is only that this isn't a big issue. I don't understand why so many see it as a large issue. Instead, projects use non-standard YAML or other problematic solutions only because "JSON doesn't have comments".
Earlier quoted context omitted.
Using includes/imports is not the greatest idea ever. Your configuration file is one of your program interface. It's something that must be well define. If your configuration file is a programing language this interface is not that well defined. Also you expose yourself to all kind of weird bugs because some (too smart for their own good) people will monkey patch your software using it. It adds a lot of unnecessary s…
> If your configuration file is a programing language this interface is not that well defined. While I do agree with the rest of your comment I don't think they were advocating using the full language for configuration, just the maps/arrays/etc. (e.g. Python's `literal_eval`).
Something like:
config = {'key1': 'value1', 'key2': 'value2'}
could be written as:
config = {}
config['key1'] = 'value1'
config['key2'] = 'value2'
With large chunk possible between the 3.
It basically transforms the configuration file into an API like any library, which is not really what you want for an end user program.
Earlier quoted context omitted.
A few weeks ago, I had about 100 config files (tomcat context.xml) which all needed fixes for common misconfigurations - if they had the misconfigurations in the first place The kind of problem that is just a little bit too hard for search and replace. It was really easy with xslt. The result had all comments preserved. I choose to reformat the files, but keeping whitespace was an option too. Now tell me if you can d…
What problems wrt entities does XML have that it has inherited from SGML and HTML? Do you mean entity expansion attacks such as million laughs? HTML has only character rather than general entity references, and SGML has had the ENTLVL capacity to bound entity reference nesting since the year 1986. Edit: XML is just a proper subset of SGML by definition, hence it didn't introduce a single thing that wasn't there befor…
XML is more than the part inherited from SGML, it's also the XML culture surrounding it. Namespaces are an example of something that created an XML dialect. And of course SOAP, which actually needs the WS-I standard to explain what parts of the WS-* standards to use or ignore, and how to interprete them. And even then 2 WS-I stacks will rarely interop without trouble. Lets not blame SGML for that monstrosity
Our shop are heavy users of YAML, and we've sort of backed our way into a restricted subset of YAML. Some of them are config files, but others function closer to DSLs. I have not yet taken a look at strictyaml, but after years of use the spec definitely needs YAML, The Good Parts Treatment. One thing the author did not mention was how slow the out of box the Python YAML parser can be. This can be sped up with a call…