Graham Dumpleton wrote:
Note that the direction I am looking at here is that apache.import_module() is made to function properly in the contexts it needs to and not perform double duty in satisfying extra requirements of top level mod_python imports where it has to import stuff from site-packages. The top level imports should be treated specially and it should only defer to apache.import_module() for imports from the document tree.
Yes, I was thinking exactly along these lines myself. I have never really looked that closely at the import_module code since I never used it, but I felt I might have something useful to contribute if I did. After looking closely at it, I think you're right. The handler module loading should be handled separately and maintained separately. "Autoreloading" a handler module should be as simple as just deleting the module and everything that came with it, and then calling the loader again.
If this separation is done, I think that the distinction that has been introduced with a separate module loader in mod_python.publisher can be eliminated. The apache.import_module() can simply be replaced with that in mod_python.publisher or a modification of it to satisfy other requirements I will talk about later in future emails.
I agree; the code there is relatively simple and will probably do the job for most people. Keep it simple, and it can serve as an example for people who want to do something more sophisticated. Or they can upgrade from publisher to vampire; honestly, if you like publisher I don't know why you *wouldn't* want to upgrade to vampire :)
As far as imports from any of the above imported modules goes, the general rule should be that if it is a standard module in sys.path, then "import" is used. If it is within the document tree then apache.import_module().
Right, that's what I was trying to get at in my earlier email. Just avoid the problems of messing with the standard libraries altogether.
As far as utility modules which exist outside of the document tree which are specifically related to the web application but which aren't on sys.path and for which you want module reloading to work, apache.import_module() would still be used, but you have to specify the actual directory to the function. In some respects the ability not to specify a path to apache.import_module() should be disallowed with a path always required. Further, sys.path should no longer be automatically ammended to include the directory where the PythonHandler is defined for. And apache.import_module() should never search in sys.path.
Exactly... apache.import_module should be used only to load support modules for your application, not in general for importing. What you're doing with apache.import_module can have unforeseen side effects that you don't expect, so keeping its use restricted to ONLY modules that you KNOW need to be reloaded is the best policy. And requiring the path argument will go a long way in enforcing this.
The implication of not extending sys.path automatically is that "import" will not work to load a file in the same directory as the handler when in the document tree. This was always dangerous anyway as that module could also have been loaded by apache.import_module() and a problem could thus arise. If "import" is used in this way it would need to be changed to apache.import_module(), or a simple import hook introduced which when used in a module imported using apache.import_module() will use apache.import_module() underneath for an "import" of a file in the same directory.
I think that's a perfectly acceptable trade off, and it avoids potential problems that exist with the current code. I still don't necessarily think and import hook is necessary, as you've got to follow *some* conventions when you're working within a framework. And, we're really only talking about people who are going to use the handlers provided with mod_python.
How does this seem to people? There is stil more detail just in this bit which will need clarification and there are other issues as well which I haven't even mentioned.
This all looks good to me. I hate to just say "yes I agree" to everything without really adding much to the discussion, but you've clearly been thinking about it a lot longer than most people.
Nick
