Ansible bug on MacOS

[Jay Rolette]

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

[Matt Martz]

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

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/6ef150ff-4f3e-446b-88fc-75a20b6ab235%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Matt Martz
@sivel
sivel.net

[Brian Coca]

Hi Jay,

 -  no, devs don't see comments on closed bugs, pinging us here or in irc or opening a new bug would be the proper way to raise/re-raise an issue

 - no, its not a bug, 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

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.

[Jay Rolette]

Thanks Matt. Responses inline below.

Jay

On Friday, June 1, 2018 at 9:48:42 AM UTC-5, Matt Martz wrote:

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.

[Jay Rolette]

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

[Matt Martz]

> 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`.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/96ac7841-8157-435c-8d17-39777c6206ce%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Brian Coca]

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).

--
----------
Brian Coca