cmueller/ansible
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Try to clarify the wording (#59956)

Browse source 
* Try to clarify the wording

People were confused by this paragraph.  They read it as Ansible won't
auto-detect the python interpreter until 2.12.  Tried to reword it so
that they'll see that Ansible will auto-detect it currently if
/usr/bin/python is not present and in the future will always autodetect.

* Format the other instances of /usr/bin/python using :command:
This commit is contained in:
Toshio Kuratomi 2019-08-02 09:50:02 -07:00 committed by Sandra McCann
parent 1b246d89e3
commit 97d36881e2
1 changed files with 20 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

37
docs/docsite/rst/porting_guides/porting_guide_2.8.rst
View file

@ -72,13 +72,13 @@ Command line facts
Python Interpreter Discovery Python Interpreter Discovery
============================ ============================
In Ansible 2.7 and earlier, Ansible defaulted to ``usr/bin/python`` as the In Ansible 2.7 and earlier, Ansible defaulted to :command:`/usr/bin/python` as the
setting for ``ansible_python_interpreter``. If you ran Ansible against a system setting for ``ansible_python_interpreter``. If you ran Ansible against a system
that installed Python with a different name or a different path, your playbooks that installed Python with a different name or a different path, your playbooks
would fail with ``/usr/bin/python: bad interpreter: No such file or directory`` would fail with ``/usr/bin/python: bad interpreter: No such file or directory``
unless you either set ``ansible_python_interpreter`` to the correct value for unless you either set ``ansible_python_interpreter`` to the correct value for
that system or added a Python interpreter and any necessary dependencies at that system or added a Python interpreter and any necessary dependencies at
``usr/bin/python``. :command:`usr/bin/python`.
Starting in Ansible 2.8, Ansible searches for the correct path and executable Starting in Ansible 2.8, Ansible searches for the correct path and executable
name for Python on each target system, first in a lookup table of default name for Python on each target system, first in a lookup table of default
@ -105,20 +105,20 @@ Ansible 2.8:
+===========================+===============================================+ +===========================+===============================================+
| | auto | | If a Python interpreter is discovered, | | | auto | | If a Python interpreter is discovered, |
| | (future default) | | Ansible uses the discovered Python, even if | | | (future default) | | Ansible uses the discovered Python, even if |
| | | | ``/usr/bin/python`` is also present. Warns | | | | | :command:`/usr/bin/python` is also present. |
| | | | when using the fallback list. | | | | | Warns when using the fallback list. |
+---------------------------+-----------------------------------------------+ +---------------------------+-----------------------------------------------+
| | **auto_legacy** | | If a Python interpreter is discovered, and | | | **auto_legacy** | | If a Python interpreter is discovered, and |
| | (Ansible 2.8 default) | | ``/usr/bin/python`` is absent, Ansible | | | (Ansible 2.8 default) | | :command:`/usr/bin/python` is absent, |
| | | | uses the discovered Python. Warns when | | | | | Ansible uses the discovered Python. Warns |
| | | | using the fallback list. | | | | | when using the fallback list. |
| | | | | | | | | |
| | | | If a Python interpreter is discovered, and | | | | | If a Python interpreter is discovered, and |
| | | | ``/usr/bin/python`` is present, Ansible | | | | | :command:`/usr/bin/python` is present, |
| | | | uses ``/usr/bin/python`` and prints a | | | | | Ansible uses :command:`/usr/bin/python` and |
| | | | deprecation warning about future default | | | | | prints a deprecation warning about future |
| | | | behavior. Warns when using the fallback | | | | | default behavior. Warns when using the |
| | | | list. | | | | | fallback list. |
+---------------------------+-----------------------------------------------+ +---------------------------+-----------------------------------------------+
| | auto_legacy_silent | | Behaves like ``auto_legacy`` but suppresses | | | auto_legacy_silent | | Behaves like ``auto_legacy`` but suppresses |
| | | | the deprecation and fallback-list warnings. | | | | | the deprecation and fallback-list warnings. |
@ -127,13 +127,16 @@ Ansible 2.8:
| | | | fallback-list warning. | | | | | fallback-list warning. |
+---------------------------+-----------------------------------------------+ +---------------------------+-----------------------------------------------+
Starting with Ansible 2.12, Ansible will use the discovered Python interpreter
by default, whether or not ``/usr/bin/python`` is also present. Until then, In Ansible 2.12, Ansible will switch the default from :literal:`auto_legacy` to :literal:`auto`.
the default ``auto_legacy`` setting provides compatibility with The difference in behaviour is that :literal:`auto_legacy` uses :command:`/usr/bin/python` if
previous versions of Ansible that always defaulted to ``/usr/bin/python``. present and falls back to the discovered Python when it is not present. :literal:`auto` will always
use the discovered Python, regardless of whether :command:`/usr/bin/python` exists. The
:literal:`auto_legacy` setting provides compatibility with previous versions of Ansible that always
defaulted to :command:`/usr/bin/python`.
If you installed Python and dependencies (``boto``, etc.) to If you installed Python and dependencies (``boto``, etc.) to
``/usr/bin/python`` as a workaround on distros with a different default Python :command:`/usr/bin/python` as a workaround on distros with a different default Python
interpreter (for example, Ubuntu 16.04+, RHEL8, Fedora 23+), you have two interpreter (for example, Ubuntu 16.04+, RHEL8, Fedora 23+), you have two
options: options: