Graham Dumpleton wrote:
module, from the document tree. Maybe the context of the directive could be used for that ; if the directive is defined at the server or virtual host level, then it's a top level handler, otherwise if it is defined in a Location or Directory (or .htaccess file), then it's a handler that should be loaded from the document tree (with a possible fallback to sys.path if it is not found ?).
Aside from the potential security issues of storing your handler modules in the document tree, I just don't it's a good idea to traverse the document tree for a python module/package. Even in a shared hosting situation, there are still ways to store your modules outside the accessible document tree. I can just see so many confused people wondering why module B was imported instead of module A, which reside in different parts of the document tree. And module B isn't even a handler, it's a support module. Ugly. Not to mention name collision problems that are bound to happen when per directory interpreters aren't being used in that situation.
The big problem now is that if the __init__.py file uses standard import statement with the expectation that it will grab the module or package from within the same directory, it will not work. This is because to the Python import system it will not know that it is to be treated as a package and look in that local directory first.
Among other minor "gotchas" that crop up from time to time, but you've hit the big one. mod_python itelf isn't a framework as such; I'm for making mod_python accessible and usable and all that, but isn't it fair to say that mod_python doesn't have to solve *all* import problems? Handling imports automagically from your imported modules requires an import hook...
I got past this problem in Vampire through the use of the import hook. Vampire would stash a special global object in the module so the import hook knew that it was a special Vampire managed module and would grab the module from the local directory and import it using the Vampire module importing system rather than standard Python module importer. At the moment though this only works at global scope and not when import is used in the handler code when executed, although can probably solve that.
We can probably do some checks to see if we're importing a single module or an entire package without resorting to import hooks. Deal with the modules in __all__ (from __init__.py) like we'd handle single module imports, and any explicit "imports" in the package beyond that are not reloadable. Otherwise they can explicity call apache.import_module. Document this behaviour and keep it simple, otherwise people are not going to be able to debug their problems easily. Not to mention that the code will grow into a beast.
Although from/import syntax also works, if it tried to import "a.b" from a subpackage, it will not work if "b" wasn't explicitly imported by "a" to begin with.
I haven't generally experience that with import hooks, although os (and therefore os.path) seems to peskily not import because of some sys.modules manipulation weirdness.
The question thus is, if you understand what I am raving about, is whether it is reasonable that packages will not be supported by apache.import_module(). There is a slim chance some ones code may break as a result but the majority would work fine.
See above. Nick
