[sa46]

> Ansible has its own set of features that are largely abstracted out by its YAML playbook syntax.

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,
    )

> If you feel YAML is too complicated for you

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.

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

[chopraaa]

> I don't understand what YAML has to do with abstraction. The example from pyinfra is pretty much the same as the ansible equivalent.

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.

[Bystroushaak]

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