Interpreter discovery, configured · Ansible

Almost every Ansible module is Python that gets copied to the managed node and run there. Something has to decide which Python runs it, and on a host with python3.9, python3.12 and /usr/bin/python3 all present, that decision has consequences — the three do not have the same libraries installed.

INTERPRETER_PYTHON is the setting that makes the decision. Its default is auto, and auto produces a warning that most people silence.

The setting

Read-only / Safethe default— No config file present. auto is the built-in default on ansible-core 2.21.3.

$ ansible-config dump | grep '^INTERPRETER_PYTHON'

INTERPRETER_PYTHON(default) = auto

It is set in [defaults] as interpreter_python, in the environment as ANSIBLE_PYTHON_INTERPRETER, and — most usefully — as the inventory variable ansible_python_interpreter.

The supported discovery modes on 2.21.3 are auto and auto_silent. The auto_legacy and auto_legacy_silent modes existed for compatibility with older releases that always defaulted to /usr/bin/python3.

What discovery actually does

This is the part that makes the warning make sense.

Ansible runs a short shell bootstrap on the managed node that tests each candidate interpreter in turn with command -v, and takes the first one found. The candidate list is itself a setting, INTERPRETER_PYTHON_FALLBACK, and on 2.21.3 its default is exactly:

Read-only / Safethe search order, in order— The ordered candidate list discovery walks on the managed node. First match wins.

$ ansible-config dump | grep '^INTERPRETER_PYTHON_FALLBACK'

INTERPRETER_PYTHON_FALLBACK(default) = ['python3.14', 'python3.13', 'python3.12', 'python3.11', 'python3.10', 'python3.9', '/usr/bin/python3', 'python3']

Read that list top-down and the whole problem becomes visible. Newer versions are searched first. A host that today has python3.12 as its newest interpreter runs modules under python3.12. Install python3.13 on it next month — as a dependency of something unrelated, perhaps — and the very next Ansible run silently switches to python3.13.

Nothing about your automation changed. The interpreter did.

If none of the candidates is found, discovery falls back to /usr/bin/python3.

Under the hood

The mechanism is deliberately primitive, because it has to work on a host about which Ansible knows nothing yet — including whether it has a usable Python at all.

Ansible sends a single shell command built from the candidate list, of the form echo FOUND; command -v 'python3.14'; command -v 'python3.13'; ...; echo ENDFOUND, and parses the paths between the two markers. Only results beginning with / are accepted. The first one is used.

Three consequences follow.

Discovery costs a round trip. It happens once per host per run, before the first module executes. Pinning the interpreter removes that round trip, which is a small but real saving across a large fleet.

Discovery reflects PATH, not the filesystem. command -v resolves through the shell’s PATH for the account Ansible connects as. A Python present on the host but not on that PATH is not discovered.

The candidate list is settable per host or group, through the inventory variable ansible_interpreter_python_fallback. That is the right instrument for a host family with an interpreter in an unusual place, and it is a narrower change than pinning an absolute path.

The warning, and what it is telling you

With auto, after a successful discovery, Ansible emits a warning of this form on 2.21.3:

[WARNING]: Host 'web-a1.example.com' is using the discovered Python
interpreter at '/usr/bin/python3.12', but future installation of another
Python interpreter could cause a different interpreter to be discovered.

Read it precisely. It is not saying anything is wrong now. It is saying: this choice is not stable, and nothing will tell you when it changes.

That is a much more serious statement than it appears, because of what differs between two Pythons on the same host. Distribution-provided bindings are installed for one specific interpreter. On a Debian or Ubuntu host, python3-apt is installed for the system Python; if discovery picks a different interpreter that lacks it, the ansible.builtin.apt module fails with a message about being unable to import apt and apt_pkg — on a host where it worked last week, in a run that changed nothing about package management.

The same shape applies to python3-rpm on RHEL-family hosts, to SELinux bindings, and to anything else installed as a distribution Python package.

Do not fix this with auto_silent

auto_silent performs exactly the same discovery and suppresses the warning. It changes nothing about which interpreter is chosen or how stable that choice is.

Setting it globally is not a fix; it is the deletion of your only notice that a host’s interpreter could move. The warning is annoying precisely because it appears once per host per run and you have hundreds of hosts — which is a reason to remove the cause, by pinning the interpreter, not the symptom.

There is one defensible use: auto_silent in a deliberately transient context — a bootstrap play against a freshly imaged host, an ephemeral CI container — where you have accepted discovery, the host will not outlive the run, and the noise is drowning output you need to read. Even then it belongs on the play or the environment, not in the project configuration where it applies to everything forever.

The right fix: pin it where the fact belongs

The interpreter is a property of the host, so it belongs in inventory, per group, next to the other facts about that host family:

# inventory/production/group_vars/ubuntu_2404.yml
ansible_python_interpreter: /usr/bin/python3

# inventory/production/group_vars/rocky_9.yml
ansible_python_interpreter: /usr/bin/python3.9

This is better than a global setting in three ways that matter.

It is correct per host family. A single global value is wrong for any estate with more than one distribution generation, which is every estate that has been running for a while.

It is reviewable. The value is in Git, in the group’s variables file, and changing it is a commit somebody approves — unlike an interpreter that changes because apt pulled in a new Python.

It survives the thing the warning was about. Installing python3.13 on a pinned host changes nothing, because nothing is being discovered.

interpreter_python is not validated, because it doubles as a path

The setting accepts either a discovery mode or an absolute path to an interpreter. That means it has no list of permitted values — confirmed on 2.21.3, where the setting’s definition carries no choices — so any string is accepted.

ANSIBLE_PYTHON_INTERPRETER=auto_silnet ansible-playbook site.yml

ansible-config dump --only-changed reports it back cheerfully as INTERPRETER_PYTHON(env: ANSIBLE_PYTHON_INTERPRETER) = auto_silnet. Nothing complains at configuration time. The typo is treated as an interpreter path, and the failure arrives later, on the managed node, as modules failing to execute — a long way from the setting that caused it.

The same applies to a mistyped absolute path, and to auto_legacy on a version where it no longer exists. ansible-config validate catches a misspelled key; nothing catches a misspelled value here.

What happens on a host with no Python at all?

Discovery finds nothing, warns that no interpreters were found for the host after trying the candidate list, and falls back to /usr/bin/python3 — which is not there either, so the first module fails.

This is the expected state for a freshly imaged minimal host, and it is not a configuration problem to be solved with interpreter_python. The answer is to bootstrap: use ansible.builtin.raw, which sends shell commands directly and needs no Python on the far side, to install one, and only then run the rest of the automation.

That bootstrap sequence, along with minimal images, containers and the Windows case, belongs to the remote-Python part of this course. What belongs here is recognising the signature — “no python interpreters found for host”, followed by module failures — as a host that has never been prepared, rather than as a discovery setting that needs adjusting.

The setting

What discovery actually does

The warning, and what it is telling you

The right fix: pin it where the fact belongs

Knowledge check