Ansible+Mitogen ignores interpreter_python global config

[jlu5]

Hello,

I'm running the Git version of Mitogen as of commit a60c6c1. It seems that after the changes in #658, Ansible+Mitogen respects the ansible_interpreter_python variable, but not the [defaults]/interpreter_python of ansible.cfg, as described in https://docs.ansible.com/ansible/2.9/reference_appendices/interpreter_discovery.html#interpreter-discovery. Although this can be easily worked around, I do find the current behaviour a bit confusing.

---

I'm running ansible 2.9.9+dfsg-1 from Debian unstable on my host:

$ ansible --version
ansible 2.9.9
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/james/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.8.5 (default, Aug  2 2020, 15:09:07) [GCC 10.2.0]

The target machines run Debian 10 with Python 2.7.16 and 3.7.3 installed.

Expected behaviour (strategy=linear)

$ ansible staging -m setup -a 'filter=ansible_python_version'
redacted.hostname | SUCCESS => {
    "ansible_facts": {
        "ansible_python_version": "3.7.3"
    },
    "changed": false
}
redacted.hostname | SUCCESS => {
    "ansible_facts": {
        "ansible_python_version": "3.7.3"
    },
    "changed": false
}

Behaviour with strategy=mitogen_linear:

$ ansible staging -m setup -a 'filter=ansible_python_version'
[WARNING]: Platform linux on host redacted.hostname is using the discovered Python interpreter at /usr/bin/python, but future installation of another Python interpreter could change this. See
https://docs.ansible.com/ansible/2.9/reference_appendices/interpreter_discovery.html for more information.
redacted.hostname | SUCCESS => {
    "ansible_facts": {
        "ansible_python_version": "2.7.16",
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false
}
[WARNING]: Platform linux on host redacted.hostname is using the discovered Python interpreter at /usr/bin/python, but future installation of another Python interpreter could change this. See
https://docs.ansible.com/ansible/2.9/reference_appendices/interpreter_discovery.html for more information.
redacted.hostname | SUCCESS => {
    "ansible_facts": {
        "ansible_python_version": "2.7.16",
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false
}

Editted by @moreati: clarify variable vs config distinction.

[s1113950]

😱 oh no, I missed interpreter_python support when adding in #658 . Definitely a bug, not sure when I'll be able to get to this but it'll be fixed up at some point 👍 thanks for filing.

[sandinak]

As a note to this .. it also doesn't expand it if a jinja2 template is used .. which we do for venv ( ye $DIETY I wish ansible would support venv more natively!!! )

ansible_python_interpreter: "{{ lookup('env','ANSIBLE_HOME')}}/venv/bin/python"

Setting a relative path does work .. but that's not interchangable with the default strategy .. which wants a ful path.

[sandinak]

As a note to this .. it also doesn't expand it if a jinja2 template is used .. which we do for venv ( ye $DIETY I wish ansible would support venv more natively!!! )

ansible_python_interpreter: "{{ lookup('env','ANSIBLE_HOME')}}/venv/bin/python"

Setting a relative path does work .. but that's not interchangable with the default strategy .. which wants a ful path.

Just saw the PR in #658 now supported .. so ignore.

[dsgnr]

Is there a timeline of when there will be a new release? I've tested against master branch and the discovery works in my tests, but I'm unable to use it till there is a new version released.

[s1113950]

A new release will happen after #715 lands. I had planned for it to be released a lot earlier but the tests are proving to be a pain... 😞 things that work locally fail in Azure DevOps for some reason. I reeeeally wanna release before the end of the month, and I will try to make that happen.

[s1113950]

It's not ideal but in the meantime you could peg to the current master hash of the repo in your pip install as a temporary workaround to a new release :)

[yoonsikp]

Best solution is to make a group_vars/all.yml for each of your inventories, with:

ansible_python_interpreter: /usr/bin/python3

[s1113950]

@dsgnr new rc tags have been made:
https://github.com/dw/mitogen/releases/tag/v0.2.10-rc.0 -> Ansible < 2.10
https://github.com/dw/mitogen/releases/tag/v0.3.0-rc.0 -> Ansible 2.10+
both tags have the fix (not interpreter_python, but ansible_interpreter_python). They're mostly ready, aside from a few edge cases that have been found (v0.3.0 specifically, 0.2.10 doesn't have these), and some changelogs

[michaelw730]

Hi all,
the PR for this failed on a number of checks last year, is there anyway to re-run it or provide more information on the failure?
I've come across this issue with a playbook I'm running on various distros but suse12 is the only one that would need to use this setting