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

571–580 of 667 posts

Re: Why are we templating YAML? (2019)

#571

Post by throwaway894345 »

radlad wrote: post #565
throwaway894345 wrote: post #512

Earlier quoted context omitted.

Yeah, I'm pretty sure there are exactly two substantive problems with JSON for (static) configuration file use cases, which are comments and multiline strings (especially with sane handling of indentation). YAML fixes these, but it adds so much complexity in the process including such a predictable footgun of unquoted strings (the no/false problem is particularly glaring/absurd, but it's also easy to forget to quote…

Can I add "trailing commas are invalid" to the list?

Please do.

Re: Why are we templating YAML? (2019)

#572

Post by throwaway894345 »

bilalq wrote: post #531
throwaway894345 wrote: post #506

Earlier quoted context omitted.

> These same feelings extend to other proprietary config languages like HCL for Terraform, ASL for AWS Step Functions, etc. It's fine that you want a declarative API, but let me generate my declaration programatically. Yeah, I've had the same sort of opinion since the bad old AWS CloudFormation days. I wrote an experimental CloudFormation generator 4 years ago where all of the resources and Python type hints were gen…

It's an annoyingly OOP model with mutations and side-effects, but if you look past that, it's pretty nice. The core idea is you create an instance of a CDK "App" object. You create new instances of "Stack" objects that take an "App" instance as a context parameter. From there, resources are grouped into logical chunks called "Constructs" which take either a stack or another construct as their parent context param. Th…

> It's an annoyingly OOP model with mutations and side-effects, but if you look past that, it's pretty nice

I think I was getting hung up on the mutations and side-effects of it all. Thanks for putting words to that. I'll have to give it another try sometime. Have you used Terraform's CDK by chance? I assume it's heavily inspired from AWS's CDK, but my company has since moved to GCP/Terraform.

Re: Why are we templating YAML? (2019)

#573

Post by didip »

bilalq wrote: post #404

I'm completely done with configs written in YAML. Easily the worst part of Github Actions, even worse than the reliability. When I see some cool tool require a YAML file for config, I immediately get hit with a wave of apprehension. These same feelings extend to other proprietary config languages like HCL for Terraform, ASL for AWS Step Functions, etc. It's fine that you want a declarative API, but let me generate my…

For real, I want a real language (Lua/JS/Lisp) for configuration but without 3rd party imports so that it's secure and predictable.

Re: Why are we templating YAML? (2019)

#574

Post by hitchstory »

AndyKluger wrote: post #569
hitchstory wrote: post #524

Earlier quoted context omitted.

It is on my to do list to make a spec and a language independent test suite but both of these things take time.

I've asked you similar in the past in comments on this site, but: what do you find lacking in the NestedText spec that a new YAML-like format might do better? Why not just embrace NestedText for the task?

I dont know much about nested text im afraid.

Re: Why are we templating YAML? (2019)

#575

Post by pdonis »

wkat4242 wrote: post #441
pdonis wrote: post #429

Earlier quoted context omitted.

> 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.

*> I still have to mess around with spaces when editing.

Not if your editor automatically indents and dedents with spaces. I find that to work just fine when editing Python code, for example. Tab is interpreted as "indent" and Backspace if you're at an indent stop is interpreted as "dedent".

Re: Why are we templating YAML? (2019)

#576

Post by valty »

Syntonicles wrote: post #526
valty wrote: post #164

It's funny how little developers think about how to do configuration right. It's just a bunch of keys and values, stored in some file, or generated by some code. But its actually the whole ball game. It's what programming is. Everything is configuration. Every function parameter is a kind of configuration. And all the configuration in external files inevitably ends up as a function parameter in some way. The problem…

This is something I'm trying really hard to do with a client. They have a bunch of 1500+ line "config" files for products, which are then used to make technical drawings and production files. The configs attempt to use naming scheme to group related variables together. I want to migrate to an actual nested data-structure using (maybe) JSON - and these engineers absolutely will not write code, so config-as-code is a n…

Sounds like you need an SQL database. You could use SQLite.

Then provide a GUI to modify that database. You could add a bunch of constraints in the database too to ensure the config is correct.

Usually when there is plain-text files though, it's because they want it that way. It's easier to edit a text file sometimes than rows in a database. Cut/copy/paste/duplicate files and text. Simple textual version control.

Re: Why are we templating YAML? (2019)

#577

Post by valty »

Draiken wrote: post #72

I agree that YAML templating is kind of insane, but I will never understand why we don't stop using fake languages and simply use a real language. If you need complex logic, use a programming language and generate the YAML/JSON/whatever with it. There you go. Fixed it for you. Ruby, Python, or any other language really (I only favor scripting ones because they're generally easier to run), will give you all of that wi…

The problem with imperative languages in configs is that they become harder to read. Webpack configs always devolve into this.

We need better tooling to allow tracing a how final configuration values are being generated.

And a _live programming_ environment so we can see the final generated configuration in one view.

Re: Why are we templating YAML? (2019)

#578

Post by 5Qn8mNbc2FNCiVV »

The worst part about this mess is that it's all fine and dandy with any other tool as long as it's first party but as soon as you want to use another software you're stuck reading and understanding the spaghetti that Helm inevitably becomes and hope that you can configure it the way you need to.

It's come to the point that I don't even think about using most charts and just build them myself. The issue with that is that software like Prometheus, Loki, Grafana or f.e. Postgres operators are so complex that it's almost impossible do "fix" them.

This really is like that dog sitting in a burning house and saying "This is fine" because that's how most go on with their day after hitting their head for a few hours and running dozens of pipelines.

Re: Why are we templating YAML? (2019)

#579

Post by Syntonicles »

valty wrote: post #576
Syntonicles wrote: post #526

Earlier quoted context omitted.

This is something I'm trying really hard to do with a client. They have a bunch of 1500+ line "config" files for products, which are then used to make technical drawings and production files. The configs attempt to use naming scheme to group related variables together. I want to migrate to an actual nested data-structure using (maybe) JSON - and these engineers absolutely will not write code, so config-as-code is a n…

Sounds like you need an SQL database. You could use SQLite. Then provide a GUI to modify that database. You could add a bunch of constraints in the database too to ensure the config is correct. Usually when there is plain-text files though, it's because they want it that way. It's easier to edit a text file sometimes than rows in a database. Cut/copy/paste/duplicate files and text. Simple textual version control.

Sure, I agree - I'm proposing JSON as an intermediate step toward a well-defined data-model since the thousands of copied config files have evolved over time, so the data-model is a smear of backward-compatibility hacks.

What I was trying to do is get you to explain what you mean by this:

> If our code ran in real-time to show us a representation of the final configuration, and we could trace how each final configuration value was generated, then it wouldn't be a problem. [...] But no systems are designed with this capability, even though it is quite trivial to do. Configuration is always an after-thought.

Post reply on HN