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

481–490 of 667 posts

Re: Why are we templating YAML? (2019)

#481

Post by WorldMaker »

Dylan16807 wrote: post #440
WorldMaker wrote: post #437

Earlier quoted context omitted.

The defaults are either 4-space or 8-space soft tab stops. 8 spaces it the oldest soft tab behavior. 4-space soft tabs have been common for C code among other languages for nearly as many decades. It is only relatively recently that Python and JS and several Lisp-family derivatives have made 2-space tab stops much more common of a style choice. Unfortunately there is no "perfect" default as these are as aesthetic pre…

Soft tabs at 4 would be fine, though worse than autodetect. But that is not the behavior described in the above post.

The behavior described above seems to me to be exactly soft tabs at 4 in a 2-space tab document with autoindent turned on (often the default).

Vim has no autodetect by default. (I'm sure there's a plugin somewhere.)

Re: Why are we templating YAML? (2019)

#483

Post by shortrounddev2 »

zamalek wrote: post #462
shortrounddev2 wrote: post #455

Earlier quoted context omitted.

I've always wondered why we seem to have implemented a whole programming language in yaml or json for so many CI/CD systems rather than just writing quick python scripts to describe the logic of a particular build step, then MAYBE using a JSON or XML file to enumerate the build steps and their order, like: build: src/build.py test: src/test.py

Sure, that's orchestration, though. The problem with GHA is the sheer amount of expressive power that it has. If you need to do dynamic stuff then that should be in a "pre-workflow" step, written however/in whatever you please, that emits the actual workflow.

Why shouldn't the python script be the discrete workflow step? It could be mounted on some file system which has checked out the git at a particular commit with a particular tag, then runs whatever tasks are required to validate or deploy the project

Re: Why are we templating YAML? (2019)

#484

Post by sterlind »

unshavedyak wrote: post #432
zamalek wrote: post #378

Earlier quoted context omitted.

The problem goes deeper. I can't remember who coined the term, but all "implerative" (imperative declarative) languages share the same issue. I don't care if it's JSON, XML, TOML, or YAML, we shouldn't be interpreting markup/data languages. GitHub actions are a good example of everything wrong with implerative languages. Use a real programming language, you can always read in JSON/YAML/whatever as configuration. Goog…

Oh man, i have a similar issue with NixLang. Though i know it's not "implarative". Many days i just want to write Nix in my preferred language. I wish Nix had made a simple JSON based IO for configuration, because then i could see what the output of something is - and generate the input state from some other language. Really frustrating. Nix works.. but i just don't see the value, personally. And this is after living…

Nix can read JSON, there's a deserializer as one of the builtins you can call. So you can make a bridge where Nix reads your JSON and does something with it, and you can generate the JSON externally like you want. It's how things like poetry2nix work.

Re: Why are we templating YAML? (2019)

#485

Post by DrBazza »

TheFuzzball wrote: post #26

I just knew this would be about Kubernetes when I saw the title. The Kubernetes API is fairly straightforward, and has a well-defined (JSON) schema, people should be spending a bulk of their time learning k8s understanding how to use the API, but instead they spend it working out how to use a Helm chart. I don't think Jsonnet, Ksonnet, Nu, or CUE ever gained that much traction. I'm convinced most people just use Kust…

We're using jsonnet for our systems and they have absolutely nothing to do with k8s. I'm not sure it's true to say it has ever gained much traction. It's just a niche case for complex configuration, and isn't the most publicised tool.

It does precisely what we need with zero fuss, cross platform and cross _language_ (we've embedded it in C++, .NET, and JVM executables).

We can use the resulting json config with a vast array of tools that simply don't exist for the alternatives such toml/yaml/hocon/ini whatever. In fact we tried to get HOCON working for non-JVM languages but there was always some edge case.

Re: Why are we templating YAML? (2019)

#486

Post by lolinder »

weebull wrote: post #465
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…

GitHub actions would suck whatever you "configured" them in, because you are trying to describe a program in a data structure. Ansible makes the same mistake, as do countless other tools.

> you are trying to describe a program in a data structure

This describes 100% of software development, though! Programming is just designing data structures that represent some computation. Each language lends itself better to some computations than to others (and some, like YAML, are terrible for describing any kind of computation at all), but they're all just data structures describing programs.

The problem isn't that GitHub Actions tries to describe a program in a data structure, the problem is that the language that they chose to represent those programs (YAML and the meta language on top) is ill-suited to the task.

Re: Why are we templating YAML? (2019)

#487

Post by btown »

tomjakubowski wrote: post #472
weebull wrote: post #465

Earlier quoted context omitted.

GitHub actions would suck whatever you "configured" them in, because you are trying to describe a program in a data structure. Ansible makes the same mistake, as do countless other tools.

"because you are trying to describe a program in a data structure" (cries in lisp)

I often wonder if the only reason we haven't used lisp more as a society, and certainly in the devops world, is because our brains find it easier to parse nested indentation than nested parentheses.

But in doing so, we've thrown out the other important part of lisp, which is that you can use the same syntax for data that you do for control flow. And so we're stuck in this world where a "modern-looking" program is seen as a thing that must be evaluated to make sense, not a data structure in and of itself.

https://www.reddit.com/r/lisp/comments/1pyg07/why_not_use_in... is a fascinating 10 year old discussion. And of course, there's Smalltalk, which guided others to a treasure it could not possess. But most younger programmers have never even had these conversations.

Re: Why are we templating YAML? (2019)

#488

Post by lamontcg »

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…

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

The problem is language nerds write languages for other language nerds.

They all want it to be whatever the current sexiness is in language design and want it to be self-hosting and be able to write fast multithreaded webservers in it and then it becomes conceptually complicated.

What we need is like a "Logo" for systems engineers / devops which is a simple toy language that can be described entirely in a book the size of the original K&R C book. It probably needs to be dynamically typed, have control structures that you can learn in a weekend, not have any threading or concurrency, not be object oriented or have inheritance and be functional/modular in design. And have a very easy to use FFI model so it can call out to / be called from other languages and frameworks.

The problem is that language nerds can't control themselves and would add stuff that would grow the language to be more complex, and then they'd use that in core libraries and style guides so that newbies would have to learn it all. I myself would tend towards adding "each/map" kinds of functions on arrays/hashmaps instead of just using for loops and having first class functions and closures, which might be mistakes. There's that immutable FP language for configuration which already exists (i can't google this morning yet) which is exactly the kind of language which will never gain any traction because >95% of the people using templated YAML don't want to learn to program that way.

Re: Why are we templating YAML? (2019)

#490

Post by vimax »

m000 wrote: post #473

Yes, templating YAML is crazy. But is the answer jsonnet? That's even more batshit. Why hasn't anyone opted for a "patch-based" approach? I.e. start with a base YAML/JSON file, apply a second file over it, apply this third one, and use the result as the config. How you generate these files is entirely up to you.

Yes. The answer is a "config.d" directory, this has been known to linux package managers for a long time. It is the only way for multiple packages to contribute to configuration without fighting over ownership of the one true config file.
Post reply on HN