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

Why are we templating YAML? (2019)

leebriggs.co.uk

Post reply on HN
Print view View original

441–450 of 667 posts

Re: Why are we templating YAML? (2019)

#441

Post by wkat4242 »

pdonis wrote: post #429
wkat4242 wrote: post #117

Earlier quoted context omitted.

The biggest issue I have with Yaml is that they forbid tabs. Their argument is that tabs are shown differently in every editor which is actually something I like. When you're looking for something deeply nested you can reduce the tab distance a bit, when that's not needed you can increase it to improve visibility of nesting levels. And forbidding it makes a one-keystroke action a two or four one. I really don't under…

> forbidding it makes a one-keystroke action a two or four one. Not if your editor can be configured to interpret a Tab keypress as the appropriate number of spaces. AFAIK all common text editors, at least in the Unix world, do this.

I don't want that though, because then I still have to mess around with spaces when editing.

I actually like tabs for indenting levels especially because I can configure how far they indent on the fly.

Re: Why are we templating YAML? (2019)

#442

Post by rcfox »

calvinmorrison wrote: post #294
andybak wrote: post #231

Earlier quoted context omitted.

Tabs aren't a problem Spaces aren't a problem. What is a problem is not picking one or the other. There's arguments for both sides but it is critical to just take a side. I'm sorry your side lost but it makes everything better to just go along with the consensus.

i don't take sides, I use tabs AND spaces

"Tabs for indentation, spaces for alignment" is something I wish had caught on.

Re: Why are we templating YAML? (2019)

#443

Post by doctorpangloss »

worldsayshi wrote: post #152
ithkuil wrote: post #146

Earlier quoted context omitted.

I love the idea of keeping it simple and I do try to use kustomize or even plain yaml as installation method as much as possible. But in practice when managing large systems you inevitably end up benefiting from templating

I've begun thinking that if you start thinking about templating you might be better off building an operator. Operators aren't as well understood and documented. But in my mind an operator is just a pod or deployment that creates on demand resources using the k8s api.

Helm is a low budget operator.

Re: Why are we templating YAML? (2019)

#444

Post by solatic »

YAML is fine for human-maintained configuration. Yeah it has its footguns (like Norway) but if you're actually writing human-maintained configuration then you quickly pick these up with practice and they turn into a non-issue.

If your configuration is complicated enough that it needs to be generated, then use a real general-purpose language to generate it. Not crummy pseudo-imperative constructs bolted onto the YAML.

At the very least, systems that take YAML as configuration should also take JSON as configuration. GitOps-style systems should allow you to define, not just system.yaml config, not just system.json config, but also system.js config, that is evaluated in some kind of heavily-restricted sandbox.

Re: Why are we templating YAML? (2019)

#445

Post by arp242 »

bayindirh wrote: post #129
chx wrote: post #111

Earlier quoted context omitted.

1. I am unaware of a standardized .ini format 2. The native types in TOML are useful.

This is an .ini: [section] option=value it the way you want it. ; And these are comments. That's all. I don't argue. I use TOML too, but it doesn't change that it's an ini++. You can treat an .ini file as a TOML file (well, maybe comments needs some changing, but eh), they're not different things. I don't think, even though TOML has some official spec, all parsers are up to it, and may have disagreements between them…

> I don't think, even though TOML has some official spec, all parsers are up to it, and may have disagreements between them.

Overall it's not that bad, see e.g. https://arp242.github.io/toml-test-matrix/

If you look at the failure details then most of them are either minor issues about where things like escape characters are/aren't allowed, or about overriding existing tables (previously the spec was ambiguous on that, and I expect that will clear up over time). Note that overview is not entirely fair because it uses the latest (unreleased) version of toml-test where I added quite a few tests.

These kind of imperfections in implementations are of course true for any language, see e.g. YAML: https://matrix.yaml.info – I have no reason to believe it's worse in TOML vs. YAML, XML, JSON, or anywhere else. If anything, it's probably a bit better because it's fairly simple and has a pretty decent test suite.

Re: Why are we templating YAML? (2019)

#447

Post by mark_and_sweep »

Draiken wrote: post #226
mark_and_sweep wrote: post #171

Earlier quoted context omitted.

Agreed, and I almost feel silly for pointing this out, but for writing JSON (JavaScript Object Notation), I'd recommend using JavaScript...

JS is actually not that great for this IMO. You probably need an NPM package to even deal with YAML because JS has a shitty standard library. Sticking to a scripting language with a strong standard library is way better. Any unix system can get Ruby/Python and read/write YAML/JSON immediately without caring too much about versions. Of course in today's upside down world most developers seem to only know JS, so it wou…

Parent is talking specifically about writing JSON, not YAML.

Re: Why are we templating YAML? (2019)

#448

Post by weebull »

pclmulqdq wrote: post #363
wkat4242 wrote: post #117

Earlier quoted context omitted.

The biggest issue I have with Yaml is that they forbid tabs. Their argument is that tabs are shown differently in every editor which is actually something I like. When you're looking for something deeply nested you can reduce the tab distance a bit, when that's not needed you can increase it to improve visibility of nesting levels. And forbidding it makes a one-keystroke action a two or four one. I really don't under…

I'm pretty sure most of the "spaces" people have their editor set up to convert the 'tab' key into multiple spaces. Now excuse me while I duck under this table.

You're safe because you're right.

Re: Why are we templating YAML? (2019)

#449

Post by wkat4242 »

geerlingguy wrote: post #218
jampekka wrote: post #212

Earlier quoted context omitted.

Not everyone wants a bloated and buggy IDE to write their code for them.

Almost every text editor has support for tabs-as-spaces. I haven't used an IDE in years.

I don't want that though. Because then when editing I still have to mess around with spaces.

And the double nature of the spaces makes it hard to see when you have an odd number of spaces when you reach deep indenting levels, which counts as the lesser number of double spaces in Python.

IMO it would be ideal if tabs would be displayed as a block, and you could resize the width of that block on the fly <3

Re: Why are we templating YAML? (2019)

#450

Post by Dylan16807 »

hombre_fatal wrote: post #165
__jonas wrote: post #101

Earlier quoted context omitted.

In general I am always confused that it lets you use strings unquoted, which is what allows for all these issues with ambiguity of the interpreted data type, Norway problem and all that. It also just looks odd to me, I don't see why it's necessary to allow this.

It’s great for end users who don’t understand what a string is or don’t have to play the game of finding the hanging single quote when they write the file by hand in a textarea. On the opposite end of UX, there’s hand written JSON which is just too meticulous in some scenarios when people are writing config without editor support.

Dealing with inline quotes is annoying, but if you care about users writing things by hand, and especially in a textarea, you should not be using a format that depends on indentation.
Post reply on HN