Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Introduce ANSIBLE_PYTHON_INTERPRETER env variable. #6345
ansible 1.6 (devel da2126e) last updated 2014/03/04 20:54:15 (GMT +200)
At the moment, there is no env variable equivalent of the
If I use a python at some other path than
But if I already have an
And combining several config files is not supported.
So, how would I solve this?
Having a corresponding env variable (as with many other settings) would solve this nicely, but from what I gather from a bit of googling, that env variable is deliberately not available. How come?
Steps To Reproduce:
I would ideally want to do this:
It is not :)
Another solution to the same problem would be to have
It is not just ansible_python_interpreter, this facility works for ruby
Using env is not a universal solution either too many distros and OSs have
I'm not sure I follow. Is there a
In any case,
The logic is 'ansible_*_interpreter', so ruby, perl, any script executable
/usr/bin/python is not used for portability, it is used so you can control
The change would then be to change all occurrences so that they can still be substituted, while providing additional portability when running ansible in e.g. a virtual environment. I understand that this may be a large change with many side effects, but would still be useful.
In my specific case, I need the
When I run Ansible, it will not have that last path available, since Ansible always uses
Now, the next person who uses this repository and configuration will have the same interpreter path. But if that person has python at
How would you solve this situation?
What Brian said about this applying to all languages applies, and this is introduced to be able to manage systems where you are simultaneously talking to two systems with different interpreter paths. Thus, setting it globally defeats that purpose.
If you do need to assign it globally, it can be assigned at the group_vars/all level.
This is closed but I don't believe that the creator of this issue was understood properly. I am running into the same issue. There is no desire to set an environment variable on a remote host. The use case here is for a development host/jump host. So lets say the scope is restricted to the implicit localhost (the feature that was added in 1.5).
As an example, I am creating instances on OpenStack via the nova module, which is run on localhost. In order to make this work properly with my MacPorts version of python I need to explicitly define localhost in an inventory, then add the ansible_python_interpreter variable to the inventory entry, or follow one of the other suggestions that is essentially the same thing, explicitly defining variables for localhost.
This is an issue when you are working with others as the explicit definition for localhost that I have made in the inventory, may not be what their localhost looks like.
So the proposal is as follows, the environment variable ANSIBLE_PYTHON_INTEPRETER (or any language) would only take precedence in the localhost scope.
Otherwise it would be ignored. Its sane to defer to local environment variables to make sure a program has the proper information about how the local environment is configured.
I can also see this working fine for remote hosts as long as its reading from the local environment, i.e. pushing out an environment variable thats set on my machine to a bunch of other machines that are likely configured different makes no sense, but that is not what this discussion is intended to be about.
We also just came across it when running against localhost with sudo.
We do have use cases for many users sharing the same hostfile. For us, it is an entire devteam using a vagrant setup with ansible as the provisioner. We can have all devs using a single private ip with
We share a single ansible tree and a single hosts file for vagrant with
in a .ansiblerc file we have
This works fine for regular tasks, but for sudo tasks the LOCAL_ANSIBLE_PYTHON_INTERPRETER evaluates to null as it is not in the root env. This causes a Permission denied error as the python interpreter vanishes and the ansible module is not executable.
We develop on mac so there isn't even a /root to place a config file in.
I believe setting an ANSIBLE_PYTHON_INTERPRETER var in .ansible.cfg would solve both these issues. It should only apply to the local machine, but it should apply to all users of localhost.
+1 for setting an env variable for this.
referenced this issue
Jun 9, 2015
It's hard to believe there is still no support for this functionality. @alimony is completely correct, having to set this variable via inventory/group_vars/extra_vars just won't cut it, there are far too many use cases where this breaks portability. To name just a few:
Is anyone interested in working on this?
referenced this issue
Dec 28, 2015
This issue becomes a slight nuisance when working with official docker containers from the 'python' tag, as in entries from https://hub.docker.com/_/python/.
When trying to use the docker connector from ansible 2.0 on those containers, one will encounter this error:
There will not be an environment variable for python interpreter added to ansible. There are ways to enable all the use cases that people are asking for by setting
@dominikborkowski Your issue with docker sounds like it is the primary use case for ansible_python_interpreter. On the docker containers, python is installed into /usr/local/bin/ instead of into /usr/bin/ because of that, for your docker containers you need to tell ansible that the python executable resides somewhere other than /usr/bin/python. You do this using ansible_python_interpreter in an inventory file:
For everyone who wants to have multiple python interpreters on the same host with different users using different ones there's various methods which may suit your needs in various ways. The one closest to setting an env var is to set ansible_python_interpreter on the command line as bcoca mentioned: #6345 (comment)
If you want to set that in a shell login file so that it applies to all of your hosts (like setting an environment variable in a shell login file would do) use alias to always add that to the ansible and ansible-playbook commands:
Something similar can also be done in inventory with inventory names per-user like this:
I'm going to be locking this issue as the environment variable is probably never going to happen. If you need help getting an alternative to work, feel free to stop by the mailing list or IRC and someone will be happy to try and get an example working for you. I'll paste the mailing list information below.
Thanks very much for your interest in Ansible. It sincerely means a lot to us.
This appears to be a user question, and we'd like to direct these kinds of things to either the mailing list or the IRC channel.
If you can stop by there, we'd appreciate it. This allows us to keep the issue tracker for bugs, pull requests, RFEs and the like.
Thank you once again and we look forward to seeing you on the list or IRC. Thanks!
On IRC there was a little bit of discussion about a related issue. I'll add the information here in case it's helpful.
Sometimes people don't want to hardcode a specific python path for the remote machine, instead relying on the python interpreter that's found first in the remote machine's PATH. ansible_python_interpreter can be used to address that case as well if you have the env program installed in a reliable location. here's how you can do that in an inventory file:
ansible will then create module scripts with the shebang line of
If you have to do this at the command line that is also possible:
Note that we had to nest our quotes so that the embedded space in the variable's value was handled correctly (the single quotes are processed by the shell and then the double quotes are handled by ansible's key=value parser).