Hi Graham, Thanks for starting this thread. Here is a rundown of the (few) features I am using specific to mod_python:
* call apache.import_module * call apache.build_cgi_env * getattr req.path_info * setattr req.status * setattr req.content_type * setattr req.headers_out * call req.read * call req.write * print (stdout -> apache error log) * various status constants (e.g. apache.OK, apache.DECLINED, apache.HTTP_INTERNAL_SERVER_ERROR) I've found workarounds for almost all of these, but in a couple of cases I've had to refactor. For example, instead of apache.import_module, I'm just using the builtin __import__. I'm currently working on refactoring use of req.read. As reading from stdin is not a good idea, I'm searching for an alternative... In general, there is a lot of good documentation for setting up/ migrating to mod_wsgi for various published frameworks (e.g Pylons, CherryPy, Django). Another valuable addition to that list would be a mod_python -> mod_wsgi migration "how-to". I'd be happy to contribute my findings as well. Thanks, -aj On Jul 6, 7:06 pm, Graham Dumpleton <[email protected]> wrote: > In mod_wsgi version 3.0 there is a new feature which will make that > sort of thing much easier. Before I go into any detail though, can you > detail what features of mod_python were you using. Ie., which of the > following were you using. > > - Custom handler. > - Publisher > - PSP > - Sessions > - Cookies > > Also, what are your plans as far as replacing the mod_python request > object with something else. > > This will give me better context as to how much changes you need to > make to move away from mod_python. > > BTW, have changed subject line given that the discussion is likely to > go beyond just import issues. > > Graham > > 2009/7/7 AJ Coon <[email protected]>: > > > Sorry to wake such an old thread... > > > I've read similar responses by Graham to this issue. Philosophically I > > agree with the assertion that application code should not live under a > > web-published directory. That said, I am working on porting a mod_python > > application to mod_wsgi and want to show that it can be done with minimal > > effort and minimal impact on the current environment. Moving > > files/directories would be perceived as a bad thing in my situation, at > > least until I can prove that mod_wsgi is a viable replacement. > > > Is there some *trick* to importing files in the same directory as the wsgi > > application module? Every method I've tried (SetEnv PYTHONPATH, > > sys.path.append, WSGIPythonPath) seems to fail to achieve this effect. > > > Thanks in advance, > > -aj > > > On Tue, Apr 7, 2009 at 7:01 PM, Graham Dumpleton > > <[email protected]> wrote: > > >> 2009/4/8 adam.ec <[email protected]>: > > >> > I've just started developing applications using mod_wsgi. I am > >> > currently migrating an old and simple application from CherryPy. In > >> > CherryPy I had a separate module for internal custom functions called > >> > fn.py. It was a simple case of writing: > > >> > import fn > > >> > at the top of the main application script. Now I am trying to do the > >> > same thing with mod_wsgi and I just keep getting Internal Server > >> > Errors. When I check the apache2 error log it reports that there is no > >> > module named fn. I tried renaming it to fn.wsgi and still have no luck > >> > in accessing my custom functions. > > >> > How do I access fn.py or fn.wsgi? > > >> Take not of what is said in: > > >> http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode#Module_Relo... > > >> The short of it though is that the directory containing the script > >> file is not looked in by default for other Python module imports. It > >> is also bad practice to be explicitly adding that directory to > >> sys.path to make it work. This is because that directory will be setup > >> to be exposable via Apache access rules. If you you stick other Python > >> code in that directory, and you stuff up your Apache configuration > >> allow that directory to be served as static files, or were using > >> AddHandler to allow WSGI script files to work in the first place, then > >> external clients could download your source code. > > >> The recommended approach therefore is that WSGI script files contain > >> as little as possible and the real code of your application be placed > >> in modules located in a completely different directory, outside of any > >> directories exposed via Apache. To have that separate directory > >> searching for Python modules, for embedded mode use WSGIPythonPath > >> directive, for daemon mode use python-path option to > >> WSGIDaemonProcess, or simply add it into sys.path in the WSGI script > >> file. Do note comments in document above about how to safely add stuff > >> into sys.path. > > >> Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
