[mod_python] mod_python 3.3 importer with "import" statement

Ben Hoyt ben at micropledge.com
Thu May 31 05:46:45 EDT 2007

OOPS -- I wasn't supposed to attach that file to that post. I'll try again.

Hi guys,

We're starting a web site running on mod_python, and we've run into import
problems, specifically using

from DIR import FILE

apache.import_modulewhere DIR is a directory (not a module or package) and
file is a FILE.py file. It works with standard Python importing, but now
that we have multiple virtual servers, we need to use, but we can't quite.

Here's the long gory story:

Up till now we've just been using the standard import statement, and it's
worked fine. But now we're running two copies of our Python code-base on two
virtual servers. So there are two files called " code.py" and suchlike in
two different directories, and the imports get confused if the two are out
of sync. All as the docs explain ... because of how sys.modules is stored
without full paths.

So I've just been trying to use the new apache.import_module(), but I'm
running into various problems because we have multiple directories in our
code structure, which looks something like this:

code/code.py  # main file for mod_python usage, imports everything
code/cli.py  # command line "test harness" loader
...  # and heaps more files in each of the subdirs

"logic" and "handlers" aren't actual packages, so we thought we'd be okay
using apache.import_module() on code.py, and all the import statements
scattered throughout the code would just work (am I correct in this? if the
top-level import uses import_module, the rest will automatically?).
code.pyis actually run by modpython_gateway.py, a WSGI wrapper for
mod_python that
we modified to use import_module instead of __import__.

But the problem is that it bombs out on statements like:

from logic import errors

with "ImportError: No module named logic"

I guess this is because logic isn't a file/module, it's a directory. Is this
correct? (In .htaccess, I have PythonOption mod_python.importer.path
"['c:/www/mpledge/code']" so it definitely knows where to go, but the import
statement fallback probably doesn't. It won't help if we set sys.path,
because then we're back to the old import problems.)

In short, we're wondering the best way forward using mod_python. The options
we see are:

1) Only ever run one code base. Non-ideal.

2) Override __builtin__.__import__ with our own one that checks if it's a
directory and calls your import_module on the result, e.g.,
import_module('logic/errors'). Would this work?

3) Write a patch to modpython's import_module that adds that functionality.
But I'm guessing there's some good reason it doesn't support this -- is that

4) Change all our import statements to import_module calls. We have a lot of
them in different forms, so this would be messy. Particularly because we
want it to work in test/command-line mode too. And at the moment with import
statements it works just as well from Apache with code.py and from the
command line with "python -i cli.py". So we'd have to do if/else conditions
around all the imports, for whether it's in cli/test mode or not.

5) Look into FastCGI or something ... but we're not sure we want to go there
at this stage.

Oh, and one more thing, we're also using Cheetah, so I guess we'll have to
change its __import__s to import_module calls too...

What do you think is the best way?

Thanks for your time!


P. S. Feel free to check out the "early page" for our website (
http://micropledge.com/). Hopefully we won't be upgrading mod_python or
something when you look. :-)

Ben Hoyt, +64 21 331 841
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20070531/78182dc9/attachment.html

More information about the Mod_python mailing list