Why do you use grep in a virtualenv?
“virtualenv is a tool to create isolated Python environments.”
“Well, Ansible does not run at all, because the hashbang on the main
ansible script says “#!/usr/bin/env python” and so it picks up the
interpreter of the virtualenv and cannot even find the ansible.runner
package.”
Note: If I did say /usr/bin/python in the Ansible script, then I’d get grilled for not working inside a virtualenv and hard coding a system path. We’re totally not going there as that is a bad thing to do.
Ansible is taking the right track here by not hard coding the system path.
It seems if you want to install ansible python packages inside your virtualenv you could do that, or you could also just change the shebang line if it was causing any problems for you.
–Michael
Why do you use grep in a virtualenv?
"virtualenv is a tool to create isolated Python environments."
I merely meant that when working on a Python project the grep command
comes in use. 
And I would not expect it to fail just because I am
working in a virtualenv.
"Well, Ansible does not run at all, because the hashbang on the main
ansible script says "#!/usr/bin/env python" and so it picks up the
interpreter of the virtualenv and cannot even find the ansible.runner
package."Note: If I did say /usr/bin/python in the Ansible script, *then* I'd get
grilled for not working inside a virtualenv and hard coding a system path.
We're totally not going there as that is a bad thing to do.Ansible is taking the right track here by not hard coding the system path.
Sure, I agree. It's a dilemma. You need to work inside a virtualenv
for development.
One solution could be to use the entry_points feature of distribute
and make "pip install -e ." or "python setup.py install" set the path
to the Python interpreter. I'm not sure you would be up for that, but
it is kind of standard.
It seems if you want to install ansible python packages inside your
virtualenv you could do that, or you could also just change the shebang line
if it was causing any problems for you.
Yes, I guess I'm back to my old solution: "( deactivate ;
ansible-playbook deploy.yml )"
Thanks for thinking along with me, I appreciate it.
Regards,
Joost
No problem … difficult balancing act!
Glad there is a solution, however involved.
Hi again,
just for the record, which installation method is providing you with Ansible scripts with the /usr/bin/env python shebang? Because if you install it with pip, pip will fix your shebang and you won’t have these issues. I just checked the EPEL repo, and their Ansible package also has a /usr/bin/python shebang fixed. Using a hard-coded Python executable instead of looking for one in the path (which is what the /usr/bin/env shebang does) will make it so you can run Ansible in any virtualenv.
Are you maybe using a git checkout and sourcing the hacking/env-setup script? Because, as I said, there are better ways.
“I just checked the EPEL repo, and their Ansible package also has a /usr/bin/python shebang fixed.”
That’s curious.
The version in EPEL should mirror the upstream spec so there are no surprises:
https://github.com/ansible/ansible/blob/devel/packaging/rpm/ansible.spec
Perhaps this is something the EPEL build system is doing behind the scenes?
Perhaps Kevin Fenzi or someone can shine some light on this.
The EPEL spec shouldn't be doing anything to scripts, it just calls
setup.py build and install.
(Here's the build output from the last epel build:
http://kojipkgs.fedoraproject.org//packages/ansible/1.3.0/1.el6/data/logs/noarch/build.log
)
kevin
I opened up http://dl.fedoraproject.org/pub/epel/6/x86_64/ansible-1.2.3-2.el6.noarch.rpm and checked the ansible script. I’m not an expert on this, but having a concrete Python in the shebang here seems like the right choice for the RPM distribution. These packages aren’t meant to be used in virtualenvs anyway. This way they’ll work regardless of your virtualenv (or lack of).
I do recall some flamewars on fedora-devel back in the day.
Really with these types of things you can’t win, but /usr/bin/env is good for nearly everyone doing a checkout, especially in the age where some people have their own pythons.
It’s really a question about what produces the least number of questions about it
Someday we can create a /usr/bin/figure-it-out that contains both behaviors and magically intuits what people want to do
Hi Tin,
The system version I use comes from the PPA at: ppa:rquillo/ansible
When I install Ansible using pypi-install I get a script that uses the
full /usr/bin/python hashbang. And my trouble go away...
Count me firmly in the "use the full path to python" camp. The way I
see it, the ansible package depends on the python package, so it knows
where the Python interpreter lives and will have stored its packages
in that pythonpath.
Regards,
Joost
I think we’ve had a long enough discussion on /usr/bin/env at this point as this is a very high traffic list.
It’s going to stay as is, let’s let this thread go for now.
I had the same error when trying to put vagrant up and tun my ansible scripts:
GATHERING FACTS ***************************************************************
fatal: [127.0.0.1] => {‘msg’: “FAILED: (25, ‘Inappropriate ioctl for
device’)”, ‘failed’: True}
In my case the issue was that my ~/.ssh/config file had no entry for the new vagrant host VM, so I needed to add on that file the following entry
Host my-host-vm 192.168.111.11
Hostname 192.168.111.11
IdentityFile ~/.vagrant.d/insecure_private_key
User vagrant