Ansible bug on MacOS

Archives Ansible Project
1

There is a long-standing bug in Ansible on MacOS where it can’t find various installed python modules because it is hardcoding the python path instead of using the typical #!/usr/bin/env python to get the correct path.

https://github.com/ansible/ansible/issues/15019

It’s been around for 2+ years, but was auto-closed 4 days later by someone that thought it was a question instead of a bug report. Tons of subsequent activity on the issue describing different work-arounds and reports of it still being broken. I’m looking to see what the scoop is…

  • Bug not visible to the dev team because no one sees comments in GitHub on closed bugs?

  • Not considered a bug (if so, I would love to hear the reasoning)

  • It’s a bug, but not high enough priority to work on

  • Something else?
    Any chance we can get this fixed? The workarounds aren’t hard, but I’m assuming it trips up most developers using Ansible from a Mac and costs them time debugging time to discover the workarounds.

Thanks,
Jay

2

It is not a bug.

We hardcode /usr/bin/python and implement a functionality for that path to be specified on a per host basis using ansible_python_interpreter: see http://docs.ansible.com/ansible/latest/reference_appendices/faq.html#how-do-i-handle-python-not-having-a-python-interpreter-at-usr-bin-python-on-a-remote-machine

Additionally if you are able to utilize the “implicit localhost” which requires you to not specify localhost in inventory, ansible should use the correct python interpreter (the one used to invoke ansible-playbook/ansible): see http://docs.ansible.com/ansible/latest/inventory/implicit_localhost.html#implicit-localhost

3

Hi Jay,

We cannot use ‘env’ as that is not always the ‘correct python’ on a machine (many environments have multiple pythons installed) and if we used env, ansible_python_interpreter would not work anymore and the user would be forced to either change the machines or change the shebang on all modules.

We settled on /usr/bin/python as the default as most distributions will work out of the box w/o the user having to change anything. Some packagers do alter the shebang to default to the location of their distribution (i.e. FreeBSD /usr/loca/bin/python) and this still is compatible with the user defined ansible_python_interpreter … for the case that a user has a FreeBSD controller and Linux targets.

4

Thanks Matt. Responses inline below.

Jay

It is not a bug.

We hardcode /usr/bin/python and implement a functionality for that path to be specified on a per host basis using ansible_python_interpreter: see http://docs.ansible.com/ansible/latest/reference_appendices/faq.html#how-do-i-handle-python-not-having-a-python-interpreter-at-usr-bin-python-on-a-remote-machine

I didn’t think this applied since the problem wasn’t on the remote machine, it’s on the system where I’m kicking off the playbook. In my particular case, my playbook is using boto to create EC2 instances from my laptop. It does a bunch of subsequent actions on the instance once it’s up, but boto not loading is a localhost problem. I can see how ansible might be written where “localhost” is just another remote machine instead of special casing it. Is that what’s going on here?

Additionally if you are able to utilize the “implicit localhost” which requires you to not specify localhost in inventory, ansible should use the correct python interpreter (the one used to invoke ansible-playbook/ansible): see http://docs.ansible.com/ansible/latest/inventory/implicit_localhost.html#implicit-localhost

I’ll have to play with this one some to see how it interacts with my playbooks.

5

Hi Brian,

I appreciate you sharing the “why’s” on this. That helps tremendously. I can see where applying playbooks across multiple remote systems, each with multiple python environments, where that would get messy.

Does that apply for tasks that are running on the localhost as well? I would have assumed that the environment is setup correctly on the controller (system where ansible is launched to execute the playbook). Or does this go back to my question to Matt about whether localhost is just another “remote” machine as far as ansible is concerned?

Cheers,
Jay

6

I can see how ansible might be written where “localhost” is just another remote machine instead of special casing it. Is that what’s going on here?

Yes. target might make it more clear than remote.

7

localhost uses the same system we use for any other target, the main
difference is that we implicitly create a 'localhost' when needed, but
if you define your own, we use that instead. @sivel already linked the
docs on this implicit localhost, which includes using 'sys.executable'
as the interpreter by default, so it executes the same python as
ansible itself.

here it is again
http://docs.ansible.com/ansible/latest/inventory/implicit_localhost.html#implicit-localhost

If you define your own localhost and/or the ansible python is not the
same python you want to use (i.e virtualenv with boto installed) you
can set `ansible_python_interpreter` for the localhost (or even just
for a specific play or tasks).