[mod_python] Catalog of mod_python.publisher problems.

Graham Dumpleton wrote:
> Graham Dumpleton wrote ..
> 
>>Do we need to document properly first the perceived problems and some
>>examples of errornous behaviour? This will help to ensure we fix
>>everything and provide a basis for some tests of any new implementation.

Good idea. A battery of tests helps to demonstrate what is really 
happening. Thanks for the examples.

> Continual reloading of modules
> ------------------------------
>   [Tue Jan 25 09:04:40 2005] [notice] mod_python: (Re)importing module 'index'
>   with path set to '['/Users/grahamd/Sites/publisher/subdir-2']'
> 
> You will see how as one cycles between the two URLs corresponding to the
> modules, that the modules are reimported everytime.
> 
> Overall what is returned is correct, but it isn't efficient because each
> request is triggering a module import.

Isn't this consistent with published modules requiring unique names? The 
important thing is that the os module is not being reimported. As you 
say, it's correct, and should be emphasized in the documentation, but 
not necessarily "fixed".

> Cross contamination of modules
> ------------------------------
> Because modules of the same name are reimported on top of the existing
> module you can end up with cross contamination of modules in respect of
> global variables, functions, class definitions, module imports etc.
> 
> The most obvious problem this causes with publisher, is that one can
> suddenly have appear in a module a function from a different module. This
> function then becomes accessible using an appropriate URL via the module
> in which it doesn't belong.
> 
> Overall this is annoying and could be problematic for those unaware.

Once again, stress this limitation in the docs: Don't reuse published 
module names.

> Sticky modules obscuring real module
> ------------------------------------
> 
> Create and "index.py", "subdir-1/index.py" and "subdir-2/index.py" all
> containing:
> 
>   import os
>   def index():
>     return os.getpid(),__file__
> 
> Now cycle through accessing these in the order:
> 
>   index.py
>   subdir-1/index.py
>   index.py
>   subdir-2/index.py
>   index.py
>   subdir-1/index.py
>   index.py
>   subdir-2/index.py
>   ...
> 
> In my case this is:
> 
>   /~grahamd/publisher
>   /~grahamd/publisher/subdir-1
>   /~grahamd/publisher
>   /~grahamd/publisher/subdir-2
>   /~grahamd/publisher
>   /~grahamd/publisher/subdir-1
>   /~grahamd/publisher
>   /~grahamd/publisher/subdir-2
>   /~grahamd/publisher
>   ...
> 
> The result for this is:
> 
>   (521, '/Users/grahamd/Sites/publisher/index.py')
>   (521, '/Users/grahamd/Sites/publisher/subdir-1/index.py')
>   (521, '/Users/grahamd/Sites/publisher/subdir-1/index.py')
>   (521, '/Users/grahamd/Sites/publisher/subdir-2/index.py')
>   (521, '/Users/grahamd/Sites/publisher/subdir-2/index.py')
>   (521, '/Users/grahamd/Sites/publisher/subdir-1/index.pyc')
>   (521, '/Users/grahamd/Sites/publisher/subdir-1/index.pyc')
>   (521, '/Users/grahamd/Sites/publisher/subdir-2/index.pyc')
>   (521, '/Users/grahamd/Sites/publisher/subdir-2/index.pyc')
> 
> One can see that once one of the "index.py" files in the subdirectories is
> accessed, they become sticky and the latest one accessed from a subdirectory
> is returned instead of the top level one when it is accessed.
> 
> This one has got to be a bug.

Hmmm, yet there is a pattern. I wonder if there is some method to this 
madness.

In any case, all of your examples reuse published module names, which 
shouldn't be done in Publisher. When you abandon that practice, what 
bugs are actually left?

Here's something that misled me a few months ago (with apologies to 
Nicolas):

Create 2 modules, in the same directory, named master.py and slave.py:

master.py:

  import slave

  def hello(req):
      return slave.hello

slave.py:

  hello = "Hello, world!"

Access http://host/master/hello and "Hello, world!" appears in the 
browser. Now move the files into a subdirectory and access 
http://host/subdir/master/hello. It throws up an error:

  ImportError: No module named slave

What happened? It originally appeared as though a module could import 
adjacent modules, but this failed in a subdirectory. The reason is that 
the original directory was where the interpreter was defined (with no 
PythonPath), and so was prepended to the module search path. It doesn't 
matter where master.py is (as long as it accessible by the defined 
interpreter), but slave.py  must be in sys.path if it is to be imported 
by a published module.

This falls under the "perceived problem" category, in that it's not a 
bug, but sure looks like one at first. My own practice for coping with 
this is to set a PythonPath directive, appending a directory outside the 
DocumentRoot from which I can reliably import modules and packages 
specific to that interpreter or VirtualHost.