Would suggest the middle option: https://docs.ansible.com/ansible/latest/getting_started_ee/i...
One can use the primitives, but eventually you'll find conflict or drift. Config management becomes something else. Not worth the hassle considering inconsistent usage/placement of the 'become' keyword, the '-b' argument, and such.
EEs slot perfectly into AWX/AAP, the next logical step once you've grown tired of using the Ansible CLI.
There's a decent workaround, though, if you don't mind managing your Ansible install with `pipx` instead of your system package manager:
$ pipx install ansible --include-deps
$ pipx inject ansible psycopg2-binary --include-apps
I'd prefer to use `uv tool install` instead of `pipx`, but it's not there yet [1].You can also containerize it w/ Podman or Docker and install the deps in the container. Maybe even add an alias.
being agentless and using ssh for transport, the target hosts need only have an ip address listed in the deployment hosts inventory, aka one can address target hosts directly after creating them, given ssh access.
much of ansibles python issues are just python issues.
ansible is a very flexible tool, and idempotent behavior is largely a factor of playbook design until it hits real world limits.
The bulk of the modules essentially generate Python payloads for Ansible to ship/run/track. Most of the burden is on the controller. Not all.
The execution environment information I linked [in another comment] covers what this user points out
The fact that it makes a new connection for every command, even when just doing a loop, makes it slow as mollasses. To add insult to injury, the name Ansible means "a tool faster than light"!
The fact that there is no way to return in the middle of a task, means that I cannot use task files as functions - that is, I cannot just tell Ansible that a given file exists it should stop running this taskfile, it will stop the whole playbook or nothing.
And because I cannot add conditions to a block, that means that the best I can do is make deeply nested layers of playbooks - ie. not the Ansible way.
These are just off the top of my head - I use Ansible heavily, and curse it all the time!