[kitd]

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

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.

[dynamite-ready]

I've written a lot of Ansible in the past year. While I'm happy with the work, I'd admit to looking at some of the logic I've had to put together with clunky, esoteric constructs like `with_nested_items` and the super colloquial variable system, while thinking "it's great to be able to do this stuff, but htf am I going to explain this code to a newbie?".

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.

[delsarto]

Stuff that gets too complex you can pretty easily abstract into a role and jump into Python.

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.