3 ms·

There are basically two types of YAML file I've seen: 1. Application configuration. That would be better off as environment variables and/or JSON(5) for stru

There are basically two types of YAML file I've seen: 1. Application configuration. That would be better off as environment variables and/or JSON(5) for structured data. 2. CI/CD configuration. Those should really be scripts, because basically every such configuration file I've seen invents its own way of making conditionals anyway.

woojoo666 4y ago
Most docker compose files I've seen are not complex enough to warrant scripting, but look way better as YAML than JSON. In those cases I think StrictYaml would be a great fit. Also scripts are very different from configs. Configs are declarative, (most) scripts are imperative. If your config is complex enough then maybe you should move some logic into imperative code, but you can still have a config on top of that.
kaichanvong 4y ago
I like XML or the no. Going off to do something, entirely non-computer based could be nice. further onwards from that you might have a nice chat in one of those hidden inter-racial dimensional pubs with neither futuristic or westworld themes.
- smcl 4y ago
  What on earth does this mean
jeroenhd 4y ago
Having used yaml for anything from configuration to Gitlab CI pipelines, I can't see how JSON could possibly improve the situation. It's an ugly subset of YAML more readable by computers at the expense of being readable by humans. Yes, if you want, you can write some terrible YAML. It's your project though, you don't need to make your YAML terrible. The same is true for everything else about your configuration, code, and infrastructure. I've seen some terrible JSON configuration that used the fact that some JSON parsers will overwrite subsequent reuses of keys as a method of documentation, for example. I know that in YAML 1.2 you can just enter JSON into a YAML file and it'll work if that's what you want. I haven't found a real life example of why that would be better, though. If you're going configuration format purist, use XML. It's actually good at requiring you to follow the schema and there are XML parsers for absolutely any platform. You can write conditions in an accompanying XSLT file for "active" configuration.
- masklinn 4y ago
  > Having used yaml for anything from configuration to Gitlab CI pipelines, I can't see how JSON could possibly improve the situation. How did you even get that idea from GP’s comment? Ci/cd is literally a different item from the json/config file one.
masklinn 4y ago
> CI/CD configuration. Those should really be scripts, because basically every such configuration file I've seen invents its own way of making conditionals anyway. Hear hear. Every ci/cd is “what if we half-assed a terrible programming langage in yaml?” And apparently the world is ok with that.
- BiteCode_dev 4y ago
  There should be a law stating that if you write a new DSL, you are forced to write all the plugin for all the IDE and a debugger for it before you are allowed to publish it. For 3 months I have been working with a team leader that had the project of making all entrypoints in the program accessible from a JSON based DSL. I tried to suggest we first expose a nice regular ergonomic API, and if we can't satisfy our requirement, we then add the DSL on top. Nope. Got the PR this week. Now he leaves next month, so we will have to maintain that.

woojoo666 4y ago

Most docker compose files I've seen are not complex enough to warrant scripting, but look way better as YAML than JSON. In those cases I think StrictYaml would be a great fit. Also scripts are very different from configs. Configs are declarative, (most) scripts are imperative. If your config is complex enough then maybe you should move some logic into imperative code, but you can still have a config on top of that.

kaichanvong 4y ago

I like XML or the no. Going off to do something, entirely non-computer based could be nice. further onwards from that you might have a nice chat in one of those hidden inter-racial dimensional pubs with neither futuristic or westworld themes.

smcl 4y ago
What on earth does this mean

jeroenhd 4y ago

Having used yaml for anything from configuration to Gitlab CI pipelines, I can't see how JSON could possibly improve the situation. It's an ugly subset of YAML more readable by computers at the expense of being readable by humans. Yes, if you want, you can write some terrible YAML. It's your project though, you don't need to make your YAML terrible. The same is true for everything else about your configuration, code, and infrastructure. I've seen some terrible JSON configuration that used the fact that some JSON parsers will overwrite subsequent reuses of keys as a method of documentation, for example. I know that in YAML 1.2 you can just enter JSON into a YAML file and it'll work if that's what you want. I haven't found a real life example of why that would be better, though. If you're going configuration format purist, use XML. It's actually good at requiring you to follow the schema and there are XML parsers for absolutely any platform. You can write conditions in an accompanying XSLT file for "active" configuration.

masklinn 4y ago
> Having used yaml for anything from configuration to Gitlab CI pipelines, I can't see how JSON could possibly improve the situation. How did you even get that idea from GP’s comment? Ci/cd is literally a different item from the json/config file one.

masklinn 4y ago

> CI/CD configuration. Those should really be scripts, because basically every such configuration file I've seen invents its own way of making conditionals anyway. Hear hear. Every ci/cd is “what if we half-assed a terrible programming langage in yaml?” And apparently the world is ok with that.

BiteCode_dev 4y ago
There should be a law stating that if you write a new DSL, you are forced to write all the plugin for all the IDE and a debugger for it before you are allowed to publish it. For 3 months I have been working with a team leader that had the project of making all entrypoints in the program accessible from a JSON based DSL. I tried to suggest we first expose a nice regular ergonomic API, and if we can't satisfy our requirement, we then add the DSL on top. Nope. Got the PR this week. Now he leaves next month, so we will have to maintain that.