2009/7/7 cubsfanintampa <[email protected]>: > > 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.
In order to migrate though, are you trying to build an equivalent to the mod_python request object and mod_python APIs, and thus keep your application code the same, or are you at just trying to preserve how files are laid out in document directories but accept that application code changes are going to be required. BTW, I really don't understand how stdin comes into it as you shouldn't have been using that before unless you were actually using mod_python.cgihandler. Thus, still not clear on whether you are using a custom handler for mod_python your wrote, are using mod_python.publisher or now even mod_python.cgihandler. Can you clarify that point. Graham > 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 -~----------~----~----~----~------~----~------~--~---
