4 ms·

Well your last sentence is the whole point: What is a sensible configuration language? For example what would have been decent for Ansible?

by tajen 8y ago

atom_arranger 8y ago
A lot of JS tools now will just take a js file that exports a configuration object (`.prettierrc.js`, `.eslintrc.js`, `.babelrc.js`). I find it very sensible. - Allows code reuse. - Allows configuration to be as dynamic as you want. - Can use environment variables. I suppose there are some cases where you can't trust the user in this way (running configuration code), but I think in a lot of cases you can, and it's generally more convenient.
peterwwillis 8y ago
Good question. For a sensible language, I would model something after Apache's. Simple, direct, easy to read, easy to write, easy to extend. It's like a server admin who barely knew HTML 1.0 wrote a config format. Perfect for the things it should actually be doing. Another option is to take a simple format and extend it with another format or language. For example, you could add SQL to a simple file format, and suddenly tons of people can extend the config with some complex logic. But I also think templating and macro languages should generally die in a fire. INI files aren't bad. They aren't a language, but they are good for simple use cases and a flat structure. Yes, you can have hierarchical section names, but it's a pain. If you want to use INI, you should probably use TOML. But there's very little incentive to add a TOML parser to a simple app when they could just suck in a JSON file. (Personally, I use JSON files, but only because I'm lazy, not because it's a good idea) The biggest problem with things like Ansible is they'll give you enough rope to hang yourself. First you get defeated by whitespace. Then you get defeated by the stupid YAML rules. Then you get defeated by complexity like inheritance, namespace conflicts, and the shittiest debugging output ever. Then you get Jinja madness embedded inside Ansible madness inside YAML madness, and nobody knows how it works and can even touch it for fear of breaking everything. And of course, there is nothing that can parse it other than Ansible. I think if Ansible had been TOML+Jinja it would have worked. It would have been ugly and clunky, but it would have worked. (The engine itself and their stupid rules about structuring your project should also die in a fire, but that's a different subject)
oblio 8y ago
Chef just uses Ruby.

Well your last sentence is the whole point: What is a sensible configuration language? For example what would have been decent for Ansible?

by tajen 8y ago

Well your last sentence is the whole point: What is a sensible configuration language? For example what would have been decent for Ansible?

atom_arranger 8y ago

A lot of JS tools now will just take a js file that exports a configuration object (`.prettierrc.js`, `.eslintrc.js`, `.babelrc.js`). I find it very sensible. - Allows code reuse. - Allows configuration to be as dynamic as you want. - Can use environment variables. I suppose there are some cases where you can't trust the user in this way (running configuration code), but I think in a lot of cases you can, and it's generally more convenient.

peterwwillis 8y ago

Good question. For a sensible language, I would model something after Apache's. Simple, direct, easy to read, easy to write, easy to extend. It's like a server admin who barely knew HTML 1.0 wrote a config format. Perfect for the things it should actually be doing. Another option is to take a simple format and extend it with another format or language. For example, you could add SQL to a simple file format, and suddenly tons of people can extend the config with some complex logic. But I also think templating and macro languages should generally die in a fire. INI files aren't bad. They aren't a language, but they are good for simple use cases and a flat structure. Yes, you can have hierarchical section names, but it's a pain. If you want to use INI, you should probably use TOML. But there's very little incentive to add a TOML parser to a simple app when they could just suck in a JSON file. (Personally, I use JSON files, but only because I'm lazy, not because it's a good idea) The biggest problem with things like Ansible is they'll give you enough rope to hang yourself. First you get defeated by whitespace. Then you get defeated by the stupid YAML rules. Then you get defeated by complexity like inheritance, namespace conflicts, and the shittiest debugging output ever. Then you get Jinja madness embedded inside Ansible madness inside YAML madness, and nobody knows how it works and can even touch it for fear of breaking everything. And of course, there is nothing that can parse it other than Ansible. I think if Ansible had been TOML+Jinja it would have worked. It would have been ugly and clunky, but it would have worked. (The engine itself and their stupid rules about structuring your project should also die in a fire, but that's a different subject)

oblio 8y ago

Chef just uses Ruby.