Python (Django) under Passenger

Hi folks,

Does anyone know if Python (WSGI) is still supported under Passenger?

I’ve got a small Django site throwing errors. It looks quite similar to this: except that the reset-Passenger trick doesn’t do any good. In particular, I get the error.log entry

… and no way to tell what’s behind it. But if I poke around where that previous post indicated, I don’t see any wsgi support in the Passenger installation:

logophile:~/logs/$ ls /dh/passenger/lib/phusion_passenger/wsgi*
ls: cannot access /dh/passenger/lib/phusion_passenger/wsgi*: No such file or directory

Can anyone confirm either that they have this working, or that it’s been retired? And if it’s no longer extant: what’s the next-best alternative? FastCGI?

WSGI support is still there; the files it uses internally have just moved around a little since my post last year. The files you’re looking for are now in “/dh/passenger/helper-scripts”.

Checking the error logs, the relevant error is:

ImportError: Could not import settings 'IndefDB.settings' (Is it on sys.path? Does it have syntax errors?): No module named IndefDB.settings

The entries that you’re inserting into your sys.path in your don’t look right — none of them actually exist in the filesystem. Running the passenger_wsgi script from the command line with an empty environment will help reveal these types of issues:

env -i python /home/username/path/to/

Welp, that’s embarrassing :-/ I moved things around to test with a fresh install, and didn’t move them back.

One more question: running the script from the commandline gives me no output at all, and (of course) nothing in the http logs. Should I expect output on stderr, or is there something else obvious I’m missing?

Thanks anyway for your quick reply!
(Think I’ve answered my own question there: errors from the passenger_wsgi script indeed turn up on stderr, but the import you spotted is only triggered from inside the wsgi handler, so it goes to the passenger log I don’t have access to. Oh well. At least I know it should be possible, so it’s just a question of eliminating my setup mistakes one by one until it works.)

Running isn’t expected to do anything — but it causes Python to run through the script, which includes loading modules. So long as you don’t see any error messages, that means it’s in good shape!

I have it running again, just replying in case someone else gets confused by the same thing I was confused by: not getting errors from the script doesn’t guarantee it’s working. That’s because django loads your own modules (in particular, the settings module that I had misplaced, and any django apps that are configured in it) lazily, at the moment that passenger and wsgi pass it an http request: by then the script has already exited successfully, and the error will only show up in the passenger log (or wherever it is that Andrew found the evidence of my misconfiguration).