# /usr/bin/env on Python Azure dynamic inventory

**URL:** <https://forum.ansible.com/t/usr-bin-env-on-python-azure-dynamic-inventory/21528>\
**Category:** Ansible Project\
**Tags:** azure\
**Created:** [May 23, 2016, 6:05pm UTC](https://forum.ansible.com/t/usr-bin-env-on-python-azure-dynamic-inventory/21528 "2016-05-23T18:05:37Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Andre\_Cruz](https://avatars.discourse-cdn.com/v4/letter/a/7feea3/32.png) [@Andre\_Cruz](https://forum.ansible.com/u/Andre_Cruz)\
**Post date:** [May 23, 2016, 6:05pm UTC](https://forum.ansible.com/t/usr-bin-env-on-python-azure-dynamic-inventory/21528/1 "2016-05-23T18:05:37Z")

</div>

Hello.

I submitted a PR [https://github.com/ansible/ansible/pull/15965](https://github.com/ansible/ansible/pull/15965) to use /usr/bin/env instead of referring to a specific Python executable in the Azure dynamic inventory. This was rejected on the basis that all ansible modules had to refer to “/usr/bin/python”. Does this make sense? This script is to be run locally and if ansible is on a virtualenv the Python executable will not be the correct one.

I understand this rule when applied to modules that are run on remote machines, but in this case I think it makes sense not to hardcode the Python interpreter.

Best regards,  
André

---

<div class="post-metadata">

**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\
**Post date:** [May 23, 2016, 6:09pm UTC](https://forum.ansible.com/t/usr-bin-env-on-python-azure-dynamic-inventory/21528/2 "2016-05-23T18:09:02Z")

</div>

It does not NEED to run locally, many will execute on a delegated host that has access. Not all environments have direct access to the API they need to use.

The ‘local’ execution might be the most common use of cloud modules, but even then `env python` might not be the correct python, for localhost ansible replaces with the ‘currently executing python’ (sys.executable) which should be the correct one.

---

<div class="post-metadata">

**Author:** ![Andre\_Cruz](https://avatars.discourse-cdn.com/v4/letter/a/7feea3/32.png) [@Andre\_Cruz](https://forum.ansible.com/u/Andre_Cruz)\
**Post date:** [May 24, 2016, 9:42am UTC](https://forum.ansible.com/t/usr-bin-env-on-python-azure-dynamic-inventory/21528/3 "2016-05-24T09:42:04Z")

</div>

> The ‘local’ execution might be the most common use of cloud modules, but even then `env python` might not be the correct python, for localhost ansible replaces with the ‘currently executing python’ (sys.executable) which should be the correct one.

Are you sure it does that?

I even tried with the “devel” branch and it did not do that:

$ ansible -i contrib/inventory/azure\_rm.py azure  
ERROR! Inventory script (contrib/inventory/azure\_rm.py) had an execution error: The Azure python sdk is not installed (try ‘pip install azure’) - No module named msrestazure.azure\_exceptions

contrib/inventory/azure\_rm.py:22: Error parsing host definition ‘’‘’': No closing quotation

But I do have it installed in this environment:

(ansible)[andre@Giedi ~/work/vc/ansible]$ python -c “import msrestazure.azure\_exceptions”  
(ansible)[andre@Giedi ~/work/vc/ansible]$

If I change the /usr/bin/python call to use the “env” in azure\_rm.py everything works.

André

---

<div class="post-metadata">

**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\
**Post date:** [May 24, 2016, 2:03pm UTC](https://forum.ansible.com/t/usr-bin-env-on-python-azure-dynamic-inventory/21528/4 "2016-05-24T14:03:58Z")

</div>

Unless you specifically override this, here is the code:

[https://github.com/ansible/ansible/blob/devel/lib/ansible/inventory/ **init**.py#L457](https://github.com/ansible/ansible/blob/devel/lib/ansible/inventory/ __init__.py#L457)

---

<div class="post-metadata">

**Author:** ![Andre\_Cruz](https://avatars.discourse-cdn.com/v4/letter/a/7feea3/32.png) [@Andre\_Cruz](https://forum.ansible.com/u/Andre_Cruz)\
**Post date:** [May 24, 2016, 2:08pm UTC](https://forum.ansible.com/t/usr-bin-env-on-python-azure-dynamic-inventory/21528/5 "2016-05-24T14:08:21Z")

</div>

How could I have overridden this? I didn't pass any flags in the command line and the only env vars set are the ones 'hacking/env-setup' put there.

André

---

<div class="post-metadata">

**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\
**Post date:** [May 24, 2016, 3:18pm UTC](https://forum.ansible.com/t/usr-bin-env-on-python-azure-dynamic-inventory/21528/6 "2016-05-24T15:18:02Z")

</div>

did you define localhost in inventory?

---

<div class="post-metadata">

**Author:** ![Andre\_Cruz](https://avatars.discourse-cdn.com/v4/letter/a/7feea3/32.png) [@Andre\_Cruz](https://forum.ansible.com/u/Andre_Cruz)\
**Post date:** [May 24, 2016, 3:20pm UTC](https://forum.ansible.com/t/usr-bin-env-on-python-azure-dynamic-inventory/21528/7 "2016-05-24T15:20:02Z")

</div>

This is the dynamic inventory script for Azure (azure\_rm.py). The problem is running the dynamic inventory script itself.

André

---

<div class="post-metadata">

**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\
**Post date:** [May 24, 2016, 3:22pm UTC](https://forum.ansible.com/t/usr-bin-env-on-python-azure-dynamic-inventory/21528/8 "2016-05-24T15:22:05Z")

</div>

So, just as an FYI here, I had mistakenly closed the issue yesterday, as I had thought it was for a module and not an inventory. The issue was re-opened yesterday as well.

---

<div class="post-metadata">

**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\
**Post date:** [May 24, 2016, 3:28pm UTC](https://forum.ansible.com/t/usr-bin-env-on-python-azure-dynamic-inventory/21528/9 "2016-05-24T15:28:20Z")

</div>

Ah, same mistake here, i thought this was about module execution.
