Ansible doesn't use a fixed /usr/bin/python necessarily. If you set a different python interpreter via your inventory as Justin did here and keep the remotes files, you'll notice that Ansible has replaced with /usr/bin/python with the python interpreter you have in your inventory.
*> I don't see why, when /usr/bin/env python will mostly be the correct python, it's still being enforced to use /usr/bin/python :/ .* The keyword in your sentence here is "mostly." Ansible needs to be using the intended python interpreter "*always*." I've worked in environments where the default python was way out of date and the modern version was in an alternate location. Because Ansible was forced to use a service account that did not have a profile to alter the PATH, we were forced explictly specify the python interpreter and let Ansible do it's thing. I've also worked in environments where python was in different alternate locations. Think of #!/usr/bin/python as just a placeholder, albeit it a functional one if left as is. Hope that helps answer your question. <tim/> [image: photo] Timothy Appnel Senior Solutions Architect Ansible, Inc. *•* www.ansible.com On Sun, Aug 30, 2015 at 4:06 AM, Alex Leonhardt <[email protected]> wrote: > I tried a pull request for the GCE modules (as example) to use > /usr/bin/env python instead of a fixed /usr/bin/python but that was > dismissed without real consideration of whether it actually be a good idea > (or not) nor a detailed explanation as to why it was considered "bad". > > I don't see why, when /usr/bin/env python will mostly be the correct > python, it's still being enforced to use /usr/bin/python :/ . > > Maybe someone here knows the inner details as to why?? > > Alex > > On 30 August 2015 at 02:36, Justin Phelps <[email protected]> wrote: > >> Thanks James. >> >> That is easier and I can confirm it works in CircleCI. >> >> >> On Saturday, August 29, 2015 at 2:51:26 PM UTC-5, James Martin wrote: >>> >>> Yay, 2 year old thread :). >>> >>> The way you solve this is by modifying your inventory for localhost with >>> the proper setting: >>> >>> #inventory file >>> localhost ansible_python_interpreter="/usr/bin/env python" >>> >>> >>> This will automatically pick up the active virtualenv's python >>> interpreter and modules that you've installed there, including boto. You >>> don't need to run any tasks to discover the path to the python interpreter. >>> >>> >>> On Friday, August 28, 2015 at 6:02:39 PM UTC-5, Justin Phelps wrote: >>>> >>>> I managed to fix this with these two tasks: >>>> >>>> - name: Find the path to the python interpreter >>>> command: which python >>>> register: pythonpath >>>> when: lookup('env', 'CI') == "true" >>>> >>>> - name: Set python interpreter path when in CI >>>> set_fact: ansible_python_interpreter={{ pythonpath.stdout }} >>>> when: lookup('env', 'CI') == "true" >>>> >>>> You would take out the when statements as they are specific to my >>>> testing environment. >>>> >>>> On Friday, August 2, 2013 at 9:52:32 AM UTC-5, Dan McKean wrote: >>>>> >>>>> I've been considering Ansible for creating our EC2 instances, and have >>>>> run into a problem with ansible not finding boto from either the command >>>>> line or a playbook. >>>>> >>>>> Here's the command line and response; the playbook is similar: >>>>> >>>>> ansible localhost -m ec2 -a "image=ami-0358ce33 instance_type=t1.micro >>>>> keypair=myKeypairName group=default wait=true" >>>>> >>>>> localhost | FAILED >> { >>>>> "failed": true, >>>>> "msg": "boto required for this module" >>>>> } >>>>> >>>>> >>>>> I'm running Ansible from an activated virtualenv. Ansible was >>>>> installed with pip install ansible, and boto's installed as well in the >>>>> venv (as well as globally). >>>>> >>>>> If I activate the venv and open a command prompt, I can import boto >>>>> without any problem, and a boto.connect_ec2() succeeds (there is a ~/.boto >>>>> config file present). Importing ansible and creating a Runner works >>>>> succeeds as well. I'm running this on Mac OS X. >>>>> >>>>> Any suggestions on how to fix this? Thanks! >>>>> >>>>> -- Dan >>>>> >>>>> >>>>> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/859b0572-7b3a-4716-99d1-6ef5134eb10a%40googlegroups.com >> <https://groups.google.com/d/msgid/ansible-project/859b0572-7b3a-4716-99d1-6ef5134eb10a%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/CACSH3MvAr3t-jbQmBYAw4fMwt1w9S-6pZNcCQdRQ8oOi8M0xJg%40mail.gmail.com > <https://groups.google.com/d/msgid/ansible-project/CACSH3MvAr3t-jbQmBYAw4fMwt1w9S-6pZNcCQdRQ8oOi8M0xJg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAOMCme4ztvsW6YmWM9r24yydWx0KG_zg1Y0dFHtdr9j9wQeqnQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
