I submitted a PR 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.
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.
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
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.