I have a site on webfaction that ran Django using their basic installer. It was just for fun, so I did not worry about things like maintainability, etc… A few years passed. I decided to get more serious about that site, so I decided to start using virtualenv and mod_wsgi.
I setup a virtualenv on my local machine. Upgraded for Django 1.4 to Django 1.5. Made some tweaks and everything worked. Setup an identical virtualenv on webfaction. Edited my wsgi.py file to activate the env. But things did not work. I was picking up the wrong version of Django. It was the version installed from before virtualenv.
I ssh-ed into webfaction. Activated the virtualenv. Started python and ran:
import sys for s in sys.path: print s
I could see all my paths from my virtualenv. Additionally I saw the global libs; paths starting with /usr/local… There is some documentation on the webfaction forum explaining why those global libs are there. None of them conflict with the libs I an using, so its just a minor annoyance. But I also saw all my local packages; the ones in /home/myaccount/lib/python2.7. I am using virtualenv to NOT include those. Crap!
My wsgi.py file looked like this (don’t do this):
site.addsitedir('my/virtualenv/lib/python2.7/site-packages') activate_this = '/path/to/env/bin/activate_this.py' execfile(activate_this, dict(__file__=activate_this))
I am pretty sure I got that code from older virtualenv docs. As Graham Dumpleton pointed out, that code is wrong.
The virtualenv 1.9.1 docs, section entitled “Using Virtualenv without bin/python”, says to do this:
activate_this = '/path/to/env/bin/activate_this.py' execfile(activate_this, dict(__file__=activate_this))
Along with that, put the path to the virtualenv site packages in WSGIDaemonProcess in httpd.conf. Something like this:
WSGIDaemonProcess mysite.com processes=2 threads=12 display-name=[wsgi-me]httpd python-path=/path/to/mycode:/home/me/.virtualenvs/my_app/lib/python2.7/site-packages.
The paths in python-path end up first on the sys.path list.
Problem kind of solve in an unsatisfying way. It bugs me that those local packages are still in sys.path. This could cause a problem if I upgrade one of those packages on my development virtualenv and forget to upgrade it on my production virtualenv. As I see it, there are two alternatives: 1) delete items from sys.paths in wsgi.py, 2) delete the local packages and force everything to run from a virtualenv. I am not sure what sort of strange side effects the former could create. I think I will go with the later.