Hi Graham, See responses below.
Thanks, -aj On Jul 8, 3:30 am, Graham Dumpleton <[email protected]> wrote: > > 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, Yes, this is exactly my goal. > 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. I guess I don't see these as mutually exclusive goals, or at least I don't have enough knowledge about mod_wsgi to understand why they have to be mutually exclusive. Either way, the more progress I make with this effort, the less important preserving existing directory structure is to me. So, I'd prefer to focus on the first goal (mod_python API migration). > > 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. Not using stdin directly; using req.read() (see previous list). > Thus, still not clear on whether you are using > a custom handler for mod_python your wrote, Yes, wrote a custom handler. >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 -~----------~----~----~----~------~----~------~--~---
