Comments on: Python Projects in Users’ Home Directories with wsgi

By: itjobs1

itjobs1 — Tue, 08 Dec 2009 19:13:51 +0000

Thanks for that! That's very useful. ;-)

By: Greg Allard

Greg Allard — Wed, 22 Jul 2009 19:47:58 +0000

I like the AddHandler approach more than what I was trying in this post. It is better since AddHandler will work in an .htaccess file. Which means this doesn't require a new public_python folder and doesn't require /p/ to be added to the url.

Before arriving at the solution in my post I tried using an .htaccess file and the directives I tried weren't supported in .htaccess. I didn't read the part about AddHandler so I missed that.

Something with either WSGIDaemonProcess or WSGIProcessGroup from the code in the blog post is making those applications work in daemon mode. It seems like any wsgi file that is touched will result in the code being reloaded for that project.

By: Graham Dumpleton

Graham Dumpleton — Sun, 12 Jul 2009 06:01:49 +0000

Sorry, I have been busy. For a start, look at latter part of section 'The Apache Alias Directive' in:

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

The approach here, using AddHandler and multiviews matching, is to overlay, or insert, the WSGI application into the directories containing the static files. It results in a slighter cleaner configuration that using WSGIScriptAlias and then trying to overlay static resources on top of the WSGI application. Using AddHandler means you can add both WSGI applications and static files without needing to change Apache configuration and restart Apache.

I have ignored daemon process groups for the moment, but can still be used in conjunction with this approach.

By: Greg Allard

Greg Allard — Thu, 09 Jul 2009 15:06:15 +0000

I tried it without the LocationMatch directives and it works with just having AliasMatch in there for the static locations.

I didn't expect that WSGIDaemonProcess wouldn't expand the python_project_name. I was doing that so that each project would have a different process so touching one wsgi file wouldn't effect another project. It seemed like it was working like that.

If you can figure out a better way of doing this that would be awesome.

By: Graham Dumpleton

Graham Dumpleton — Thu, 09 Jul 2009 01:43:42 +0000

The LocationMatch would be empty at that point and serving no purpose. The Alias and AliasMatch directives will always take precedence over WSGIScriptAlias and WSGIScriptAliasMatch, thus why you don't need the SetHandler None fiddle that mod_pythoin requires.

BTW, am still looking and will post better configuration, but to start with, using:

wsgi_processes.%{ENV:python_project_name}

for argument to WSGIDaemonProcess is wrong, as that will not be expanded. Not even sure how it is working for you, as WSGIProcessGroup would be expanded and so wouldn't match the WSGIDaemonProcess and so it should give an error that you are delegating a non existent daemon process group, when request comes in and is evaluated.

By: Greg Allard

Greg Allard — Wed, 08 Jul 2009 22:26:33 +0000

Thanks for taking at look at this. I'll test it without SetHandler None when I get a chance. It is probably something I was keeping around from when I was using mod_python. I'm guessing I need to keep LocationMatch in there so that the request doesn't go to the wsgi file though, right?

By: Graham Dumpleton

Graham Dumpleton — Wed, 08 Jul 2009 21:09:37 +0000

You don’t need ‘SetHandler None’ when using mod_wsgi. That nonsense should only be required for mod_python. I also suspect you have gone about this the hard way and there is easier ways which are documented in the mod_wsgi wiki. When I get a chance I will look through what you have done properly and comment again.