Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Avoid the need for ansible_python_interpreter=python3 hack #45852
At this moment, Ansible would fail to run on most remote hosts that do only have python3 installed by default, like Fedora 27 or newer, unless the user exclicitely adds the
This is a real issue because it assumes that the user already knows which is the default ansible interpreter on that host, which may not be something he knows or even controls. Think about dynamic inventories or playbooks that would upgrade a host from a version that had python2 to one that that has python3.
This issue was aggravated by the recommandation made https://www.python.org/dev/peps/pep-0394/ which indirectly made newer distributions which ship with python3 by default to not create a symlink from
As it seems highly unlikely to be able to update the PEP with new recomandations, we should look into findina solution for ansible, one that does not cripple the UX and avoids the need to tune ansible_python_interpreter variable for each host. This should happen under the hood by detecting a missing interpreter and falling back to python3 one (caching may be desired too).
We have plans on adding functionality to address this in a future release. I believe there is another issue for it, but I cannot find it right now.
It is not yet on the roadmap, so I don't have a lot of details about it at this time, but it will likely be an optionally enabled step, run before
Yeah, I think I'm owning getting this one ready during 2.8. I've already got a working prototype of the actual interpreter detection logic (a 2-step shell + Python-backed table lookup thing)- that's kind of the easy part. The harder parts are:
The way I'm currently thinking about it, it'll be a special config value for
Anyway, this is a very high priority for me to get in for 2.8 (and hopefully pretty early) so we can start the clock on making it the default behavior as soon as possible.
@nitzmahone is likely already aware of this, but the "no /usr/bin/python or /usr/bin/python3 by default" structure in the RHEL 8 beta adds the extra autodetection wrinkle of "platform-python vs user-facing-python2 vs user-facing-python3": https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/