This is an uncharitable dismissal of a valid point. Think a bit more about the concern: is it that YAML is too hard or that it’s adding complexity in addition to that inherent to the work? You’re taking the domain-specific challenges of whatever you’re doing and adding YAML’s quirks like magic type conversion, various syntax oddities which just have to be memorized, requirement for a domain specific linter to validate things like macros, etc.; the various Ansible conventions for variable declaration and manipulation, programming language-like loops and conditionals, mix of raw Python and Jinja2 template syntax; the whole complex system for doing inventory and host/group variables; the various modules’ different implementation decisions for how they accept arguments and what they return; and the fact that those modules are wrapping other libraries which you can’t call directly (AWS adds something, wait for boto3 to add it, wait for Ansible to add it, find out that they forgot to add the optional feature you need, repeat). YAML is part of the concern and it especially adds wrinkles like needing dialect-specific editor / formatter / linter support to get the formatting and validation support which using a programming language would give out of the box but most of it comes back to using a document formatting language to write what inevitably needs to be code.

The counter-argument is that it’s easier to start with and that the high-level module interface avoids needing to write as much code. I think that’s a valid goal but it makes me wish there was an easier way to drop code into a project than writing a plugin: imagine if you hit a tricky place with the basic modules but could just drop a .py task in and have the richness of full Python with type validation telling you that an argument is incorrect before your deploy fails 10 minutes in.

I don't understand what YAML has to do with abstraction. The example from pyinfra is pretty much the same as the ansible equivalent. Whether the feature set is comparable is a different question (I agree with you, it's probably nowhere close to ansible).

    apt.packages(
        {'Install iftop'},
        'iftop',
        sudo=True,
        update=True,
    )

Ansible YAML is a poor substitute for a real language once you add conditional logic to the mix. Another huge downside is that composition in YAML is much harder than in any programming language. A Python (or dhall, or cue) library that compiled to ansible would be pretty swell.

Given that the average devops person is already stuck with yaml, many of those problems are addressed by jsonnet. But I agree, having it in the language would be preferable. I think it stems from the desire to make infrastructure declarative, which isn't really the case when your declarations are dynamic.

I'd like some kind of 'sensible', backwards compatible layer in Ansible that would allow me to rewrite stuff in raw Python, with 'normal' code, where it makes sense, but keep YAML for constructs that do actually look and work like lists of basic tasks.

https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/t... is a nice example of some pretty complex co-install of libraries for testing under tox (and you can unit test bits of it too...).

https://zuul-ci.org/docs/zuul-jobs/ is a collection of roles and playbooks that do a lot of complicated things with nice abstractions such as this. Although they're designed to be called from the Zuul CI system, there's many good examples for anyone wanting to build out their Ansible in a scalable and maintainable way.

I said this in continuation to the line you quoted:

> You can run it across any (or almost) system, from Linux to Windows and even networking devices. You can create modules in any language you want.

This is abstracted in YAML so that anyone who uses any modules does not need to know the language it is written in. Only the YAML syntax.

And the declarative and imperative language you've built on top of that.