Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Defense of YAML

blog.atomist.com

Post reply on HN
Print view View original

151–160 of 173 posts

Re: In Defense of YAML

#151

Post by actionowl »

yongjik wrote: post #103
actionowl wrote: post #4

You want to see a real abuse of YAML? Take a look at SaltStack's Jinja rendered YAML. I just grabbed a random forumla as an example: https://github.com/saltstack-formulas/openssh-formula/blob/m...

Yep, saltstack is a dumpster fire. Each jinja template can call arbitrary Python functions, and usually brings in external data from somewhere, so if something fails you have a jinja template that imported arbitrary data into a YAML format which defined multiple action items that are executed in some hard-to-understand order and good luck figuring out what went wrong where. Jinja/salt usually wouldn't even tell you w…

After years of using Salt (and contrinbuting upstream patches and PRs), I've finally given up on it entirely. There are too many reasons to include here but it indeed has turned from something useful and promising into a total dumpster fire.

Re: In Defense of YAML

#152

Post by stubish »

marcyb5st wrote: post #39
jasonhansel wrote: post #29

I really want a good "universal" configuration language (like https://dhall-lang.org/ ) that can be used to generate arbitrary text files (e.g. nginx configurations, JSON, YAML, etc.)

So, my opinion is based only on perhaps 1h playing with it. I have mixed feelings about this. It's definitely neat, but I don't like that it adds quite a bit of cognitive overhead (again, this might be because I'm not fully used to it). I believe configurations shouldn't force you to think "how will this be rendered?". For my personal projects I started using protobuffer text formats as configurations. Having the pro…

Is there any particular advantage to text format protobufs, rather than the JSON or YAML representations? I've avoided the text format, as I couldn't find it documented, and it seems easier to unmarshal YAML or JSON using the Python or Go APIs.

I do agree that your approach seems good. Alternatives such as jsonschema seem to have much worse syntax, tooling and language support. And we don't discuss XML schemas in polite company.

Re: In Defense of YAML

#153

Post by stubish »

falsedan wrote: post #27
gaogao wrote: post #15

You can actually use Python as a configuration file pretty well, if you need more complicated logic and macros. Otherwise, sticking to a toml or ini file is my preference.

INI is the best config format imo since you can't do anything more complicated than assigning a value to a key in a namespace. The Dist::Zilla config file was a real eye-opener at what you can achieve with this kind of siimplicity.

You need to specify which INI config file format, unfortunately. There are many different ways to handle leading & trailing whitespace, quoting, multiline strings etc. and I think all of them have been implemented at some point.

Re: In Defense of YAML

#154

Post by stubish »

ams6110 wrote: post #61
fendy3002 wrote: post #42

While there are no other format with clear advantage over YAML, I wonder why nobody use javascript with modules as programmable configuration. Can be broken to file parts, support comment, variable, functions or scripts. And with additional extension can import packages. Though the downside may be JSON format that's noticably bigger than yaml.

I think JSON is almost always better than YAML, except for very simple cases.

I feel it is always better for programs to accept YAML than JSON, because then you can feed it either YAML or JSON (all valid JSON is also valid YAML).

Re: In Defense of YAML

#155

Post by zaphar »

simtel20 wrote: post #147
zaphar wrote: post #35

Earlier quoted context omitted.

It's really easy to generate invalid YAML with a templating language if you aren't careful. If you like tooling that protects you from yourself and others mistakes then using a template language to generate YAML is going to ring warning bells for you.

True, but once you get it right once, it's really easy to generate the correct yaml over and over again because the input is not unknown random data.

The problem is that in practice you are modifying these somewhat frequently and if you aren't careful one of those modification will result in a production outage.

Re: In Defense of YAML

#156

Post by weberc2 »

simtel20 wrote: post #146
weberc2 wrote: post #56

Earlier quoted context omitted.

> Helm 3 introducing lua Oh, this is cool! I've actually been thinking for a while that things like Helm or CloudFormation templates or other infra-as-code things would be better served by something like Starlark, but Lua probably suits as well.

Have you looked at the work being done by stripe on skycfg? https://github.com/stripe/skycfg has the advantage of preserving protobuf message types as they're passed, so you get type checking.

I'm aware of it, but I haven't looked much at it. I'm a little confused about its scope--is it for building out protobuf specs and Kubernetes config files? Or does it somehow use protobuf specs to build out Kubernetes config files?

Re: In Defense of YAML

#157

Post by jasonhansel »

zaphar wrote: post #34
jasonhansel wrote: post #29

I really want a good "universal" configuration language (like https://dhall-lang.org/ ) that can be used to generate arbitrary text files (e.g. nginx configurations, JSON, YAML, etc.)

https://jsonnet.org/ exists and I've been playing around with a project that has similar goals https://ucg.marzhillstudios.com ucg is very much not ready for prime time yet but I think it's getting close.

JSonnet looks cool! I look forward to seeing your project also.

Re: In Defense of YAML

#158

Post by tracker1 »

jasonhansel wrote: post #29

I really want a good "universal" configuration language (like https://dhall-lang.org/ ) that can be used to generate arbitrary text files (e.g. nginx configurations, JSON, YAML, etc.)

At that point, why not just use bash?

Re: In Defense of YAML

#159

Post by tracker1 »

simtel20 wrote: post #148
maelito wrote: post #87

A substantial part of the french social and tax system is being coded as free software. One of the teams writes the source code in YAML. It's not a programming language, but rather a specification for calculable parts of the law. A JS programm then generates Typeform-like simulators, a node library, and an online interactive documentation (it is now compulsory for french administrations to explain their algorithms).…

Is something typed and better structured (e.g. protobufs) an option?

You can edit YAML with any text editor... how do you edit protobuf files?

Re: In Defense of YAML

#160

Post by tracker1 »

undecisive wrote: post #52

This whole argument pivots on the idea that you don't need code in your data. Sure, you should wrap up all the shell commands you plan to use into code fragments that you can reference. It's neater that way. Suddenly, you have 50 beautifully unit tested objects in your code, each encapsulating a different way you planned on using 'grep'. And then you open-source your tool, and hundreds of people descend on it and yea…

Thank you... couldn't agree more. It's probably the best option I've encountered for configurations... Hell, look at apache, Ms config files, xml config files, they are all nightmarish compared to YAML. Short of an actual shell script language, it's about as good as we'll ever see.
Post reply on HN