Django / Apache / mod_wsgi does not use Python virtual binary

Question

I have virtualenv at / opt / webapps / ff / with its own Python installation. I have a WSGIPythonHome installed in / opt / webapps / ff in my Apache configuration file (and this is definitely used to some extent, because if I installed it in a slightly different existing directory and restarted Apache, I would get 504). But if I, for example. assert False in the view somewhere, to open the Django debug page, I see that settings.PYTHON_BIN /usr/bin , not /opt/webapps/ff/bin .

How to get Apache / mod_wsgi to use my virtual Python environment? I thought setting up WSGIPythonHome is a way to do this, but it seems to only affect which package site directory is used, and not which binary is used. Thanks.

Answer 1

These are the instructions I used that seem to work well.

http://code.google.com/p/modwsgi/wiki/VirtualEnvironments

Using 'site.addsitedir ()' is slightly different than just adding a directory to 'sys.path' as ​​a function will open any ".pth" files located in the directory and process them. This is necessary to ensure that any special directories associated with Python Eggs are automatically added to 'Sys.path'.

Note that although virtualenv includes a script 'activate_this.py' that a virtual license application must be called using 'execfile ()' in the mod_wsgi context, you may want to be careful using it. This is because the script modifies 'sys.prefix', which can actually cause problems with mod_wsgi working, or Python modules are already loaded into the Python interpreter if the code depends on the value of 'sys.prefix' does not change. The WSGIPythonHome directive already described above should be used if you want to associate Python as a whole with a virtual environment.

Despite this, the 'activate_this.py' script is an attempt to resolve the issue of how "site.addsitedir ()" works. That is, any new directories that are added to 'sys.path' from 'site.addsitedir ()' are actually attached to the end. The problem with this in the context of mod_wsgi is that if WSGIPythonHome was not used to communicate mod_wsgi with the original base environment, then any packages / modules in the main Python installation will still be a priority over the virtual environment.

To get around this problem, that 'activate_this.py' does invoke 'site.addsitedir ()', but then also reinstalls sys.path ', so that all new directories are pushed to the foreground from' sys.path '. This will then ensure that where there are different versions of packages in the virtual environment that they take precedence over those in the main Python installation.

As explained, because “activate_this.py” does other things that might not be acceptable in the mod_wsgi context if it cannot set WSGIPythonHome to the mod_wsgi point in the original base environment, instead of just calling 'site.addsitedir ()' you should use the code:

 ALLDIRS = ['usr/local/pythonenv/PYLONS-1/lib/python2.5/site-packages'] import sys import site # Remember original sys.path. prev_sys_path = list(sys.path) # Add each new site-packages directory. for directory in ALLDIRS: site.addsitedir(directory) # Reorder sys.path so new directories at the front. new_sys_path = [] for item in list(sys.path): if item not in prev_sys_path: new_sys_path.append(item) sys.path.remove(item) sys.path[:0] = new_sys_path 

If you still want to use the activation script from virtualenv, then use:

 activate_this = '/usr/local/pythonenv/PYLONS-1/bin/activate_this.py' execfile(activate_this, dict(__file__=activate_this)) 

If the fact that 'sys.prefix' was a change does not give a problem, then Great. If you see subtle inexplicable problems that may be related to change to 'sys.prefix', then use the longer approach above where 'site.addsitedir ()' is used directly and 'sys.path' reorderd in the future.

This issue is also discussed here.

http://groups.google.com/group/modwsgi/browse_thread/thread/466823f087070b5f?pli=1

Answer 2

If you are using virtualenv, you definitely need to activate it in the WSGI script.

 venv_path = "/opt/webapps/ff" activate_this = os.path.join(venv_path, "bin/activate_this.py") execfile(activate_this, dict(__file__=activate_this)) 

Answer 3

I had the same situation in a Pylons application, and instead I used the /usr/bin binary plus the site-packages virtual directory.

Of course, it was the same version of python ...

Answer 4

I ran into the same problem when installing modoboa (based on django) in virtualenv.

It took me a long time to find a clear answer, so I will post it here.

All I had to do was add two lines to the shared apache conf file (/etc/httpd/conf/httpd.conf on CentOS):

 WSGISocketPrefix /var/run/wsgi ## (location for the PID) WSGIPythonHome /path/to/virtualenv 

And restart Apache