The reason I was cool on 'activate_this.py' was that it stomped on the value of 'sys.prefix'. Part of the reasoning behind giving that as the recipe was a distrust of the 'activate_this.py' script that is included in a Python virtual environment and advertised as the solution to use for embedded Python environments such as mod_wsgi. Site.addsitedir(directory) # Reorder sys.path so new directories at the front. Prev_sys_path = list(sys.path) # Add each new site-packages directory. Import site # Remember original sys.path. The mod_wsgi documentation on this steers you towards a convoluted bit of code to include in your WSGI application to do this, explain in part why this is the safest option. If you are hosting more than one WSGI application however, and you want each to use a different Python virtual environment, then you need to do a bit more work. If using daemon mode of mod_wsgi and you are hosting only the one Python WSGI application, then you can again just rely on the 'WSGIPythonHome' directive, pointing it at the Python virtual environment you want to use. That is plain wrong, so please do not do it, doing so will see the setting be ignored completely and the default algorithm for finding what Python installation to use will be used instead. Most important is that this should refer to a directory. It is an all too common mistake that I see that people set the 'WSGIPythonHome' directive to be the path to the 'python' executable from the virtual environment. If you don't know what that is supposed to be, then you can interrogate it using the command line Python interpreter: > import sys When using mod_wsgi embedded mode, one would use the 'WSGIPythonHome' directive, setting it to be the top level directory of the Python virtual environment you wish to use.
This is because although there are better ways of using Python virtual environments with mod_wsgi available today than there used to be, I have never actually gone back and properly fixed up the documentation to reflect the changes. The pain point here is in part actually of my own creation. That said, the use of Python virtual environments was the next topic that came up in my hallway track discussions at DjangoCon US 2014.
You should be using Python virtual environments and if you don't know why you should, maybe you should find out.
0 kommentar(er)
