Comments on: TurboGears 2 (TG2) with mod_wsgi and virtual environments http://getmediacore.com/blog/turbogears-2-tg2-with-mod_wsgi-and-virtual-environments/ Thu, 26 Aug 2010 19:36:34 -0700 http://wordpress.org/?v=2.8.6 hourly 1 By: Graham Dumpleton http://getmediacore.com/blog/turbogears-2-tg2-with-mod_wsgi-and-virtual-environments/comment-page-1/#comment-24 Graham Dumpleton Thu, 14 May 2009 02:27:05 +0000 http://getmediacore.com/blog/?p=103#comment-24 One more thing. Use of site.addsitedir() has ordering issues for directories. So long as using mod_wsgi 2.4 or later, you are better off using 'python-path' option for WSGIDaemonProcess and daemon mode, or WSGIPythonPath if using embedded mode. These will correctly reorder to the path to ensure virtual environment stuff comes before same packages installed in system wide Python site-packages directory. The ordering issues are mentioned in: http://code.google.com/p/modwsgi/wiki/VirtualEnvironments Which reminds me I need to update it to say the directive ways of doing it now fixup order as of mod_wsgi 2.4. That document describes some Python code to do reordering if doing it from WSGI script file and the ordering becomes an issue. One more thing.

Use of site.addsitedir() has ordering issues for directories. So long as using mod_wsgi 2.4 or later, you are better off using ‘python-path’ option for WSGIDaemonProcess and daemon mode, or WSGIPythonPath if using embedded mode. These will correctly reorder to the path to ensure virtual environment stuff comes before same packages installed in system wide Python site-packages directory. The ordering issues are mentioned in:

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

Which reminds me I need to update it to say the directive ways of doing it now fixup order as of mod_wsgi 2.4. That document describes some Python code to do reordering if doing it from WSGI script file and the ordering becomes an issue.

]]> By: Graham Dumpleton http://getmediacore.com/blog/turbogears-2-tg2-with-mod_wsgi-and-virtual-environments/comment-page-1/#comment-23 Graham Dumpleton Thu, 14 May 2009 02:14:42 +0000 http://getmediacore.com/blog/?p=103#comment-23 The error "Invalid command 'WSGIDaemonProcess', perhaps misspelled or defined by a module not included in the server configuration", would occur for mod_wsgi on Windows or if using Apache 1.3, as daemon mode not supported in those cases. In odd cases where Apache Runtime Library not compiled with thread support, would also not be available either. APR is still sometimes not compiled with thread support on BSD systems for some reason. In respect of gotcha 1, the libexpat problem is not an issue for Python >= 2.5. This is because pyexpat properly namespace prefixes its own version, so should be in conflict. In respect of gotcha 3, this can be more than an permissions problem. For mod_wsgi embedded mode the PYTHON_EGG_CACHE may be calculated as a stupid value based on root home directory. In that case may be necessary to use WSGIPythonEggs directive to set alternate location in Apache configuration for embedded mode. One can also use 'python-eggs' option to WSGIDaemonProcess to override the location. In both cases, as you do, you can also just set PYTHON_EGG_CACHE in os.environ in the WSGI script file. This only solves the location issue. As you point out, that new location still has to be writable by Apache user if running embedded mode and user that daemon process runs as, default is still Apache user, if running daemon mode. If you run daemon mode as a specific user, then by default will correctly use location in home directory of that user, if you don't set it, and if that is yourself will be able to write it properly. Thus, if you have no concerns about it, often easier just to setup daemon process to run as yourself. If doing that, the directories down to the location of the WSGI script file still have to be readable/search to Apache user, but the WSGI script file itself and all your Python code doesn't need to be and only needs to be accessible to you. This is useful if on a shared system and don't want to make it any easier for other users to see your code. The error “Invalid command ‘WSGIDaemonProcess’, perhaps misspelled or defined by a module not included in the server configuration”, would occur for mod_wsgi on Windows or if using Apache 1.3, as daemon mode not supported in those cases. In odd cases where Apache Runtime Library not compiled with thread support, would also not be available either. APR is still sometimes not compiled with thread support on BSD systems for some reason.

In respect of gotcha 1, the libexpat problem is not an issue for Python >= 2.5. This is because pyexpat properly namespace prefixes its own version, so should be in conflict.

In respect of gotcha 3, this can be more than an permissions problem. For mod_wsgi embedded mode the PYTHON_EGG_CACHE may be calculated as a stupid value based on root home directory. In that case may be necessary to use WSGIPythonEggs directive to set alternate location in Apache configuration for embedded mode. One can also use ‘python-eggs’ option to WSGIDaemonProcess to override the location. In both cases, as you do, you can also just set PYTHON_EGG_CACHE in os.environ in the WSGI script file. This only solves the location issue. As you point out, that new location still has to be writable by Apache user if running embedded mode and user that daemon process runs as, default is still Apache user, if running daemon mode.

If you run daemon mode as a specific user, then by default will correctly use location in home directory of that user, if you don’t set it, and if that is yourself will be able to write it properly. Thus, if you have no concerns about it, often easier just to setup daemon process to run as yourself. If doing that, the directories down to the location of the WSGI script file still have to be readable/search to Apache user, but the WSGI script file itself and all your Python code doesn’t need to be and only needs to be accessible to you. This is useful if on a shared system and don’t want to make it any easier for other users to see your code.

]]>