@jpmens Interesting. Just a first impression here but they seem to be using subprocess and Popen to run Ansible. Which is a red flag imho because Ansible lib already has all you need to run Ansible from another software as a library.
Instead they've opted to execute subprocesses with Ansible. This is prone to errors, limited, slow and it also shows a potential lack of understanding of Ansible internals.
@jpmens Hmm looking at the Ansible Python API docs I might have answered my own question.
The Ansible Python API can change at any time, breaking backwards compatibility. It's not recommended for external use, in fact they recommend using ansible-runner that you linked to. So maybe I'm wrong about that project, either way I'd rather see a project use Ansible library to minimize overhead of executing external files.
A decent implementation is basically the design of AWX. Use Ansible lib to execute plays, use Ansible callback plugin to process the output and do all this in async jobs like rq or celery for example. Anything else is just a poor man's Ansible UI.
@stemid ansible was installed systemwide, and sometimes there is a need to install a more recent version than the one in debian stable to be able to use their features.
Also, fixing versions in requirements.txt is pretty bad from a security point of view and is better avoided.
Anyway, if the authors of a library recommend not to use that library, I tend to read that as a strong hint that things will break in horribly to debug ways, and stay. away. from. it.
@valhalla Wasn't it enough to lock the ansible version you were using with requirements.txt? That would at least stabilize dev for you until you can test and upgrade to a new version.
I still think this is a sad state that everyone are just using system() to run ansible when there is a decent library.
@jpmens@stemid that's also what I saw when I tried to write something that used ansible, and the exact reason why I decided to run the ansible command instead.