[ http://issues.apache.org/jira/brows...237
5851 ]

Graham Dumpleton commented on MODPYTHON-154:
--------------------------------------------

The new module importer was already always looking in Python*Handler directo
ry when defining the handler using the actual Python*Handler directive even 
if PythonPath was set. It was only for direct use of "import" statement or "
apache.import_module()" fun
ction that it was ignoring the directory associated with the Python*Handler 
directive for the current request when PythonPath was being set.

Thinking about this, since use of the "import" statement or "apache.import_m
odule()" in the handler root directory will look at that directory anyway, b
y tracking back and see where the import is being done from, one questions w
hether it should look in th
e handler root directory at all in cases where the import is from a sub dire
ctory, or even a completely different directory outside of that part of the 
document tree.

The problem with doing this can be seen where there are a common set of modu
les used by two web applications with different handler roots but which wron
gly are not running in distinct interpreters. If both handler roots had a co
nfig module in them and the
common code wanted to import the config module, whichever handler root was a
ccessed first would have its config module loaded. When the other web applic
ation was accessed, it would use the wrong config.

Thus, conclusion at this point is that the code should never look back into 
the handler root directory. The only case this would occur is where the impo
rt was being done from within the handler root directory itself.

Alternatively, a slight variation on this could be done. That is, if the loc
ation of the file the import is being done from is within the directory tree
 rooted at the handler root, then allow it to look back in the handler root.
 If the import was being do
wn from outside of the directory tree though, it should not look back at tha
t handler root.

If a change is made, there is a danger that some old code would no longer fu
nction. Would suggest that to cope with that a PythonOption be used to enabl
e the old questionable behaviour. The option though would only exist though 
so that code could run in t
he first instance prior to its structure being redone to work in a more pred
ictable fashion.

> PythonPath overriding use of Python*Handler directory.
> ------------------------------------------------------
>
>          Key: MODPYTHON-154
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-154
>      Project: mod_python
>         Type: Sub-task

>   Components: importer
>     Reporter: Graham Dumpleton
>     Assignee: Graham Dumpleton

>
> The behaviour of the old importer is such that if the PythonPath directive
 has been used in the same or parent configuration context, then any physica
l directory corresponding to where the Python*Handler directive was used, is
 not added to sys.path.
> The new importer currently preserves the above behaviour, but since the new import
er does not actually add the directory associated with the Python*Handler directive 
into sys.path, it doesn't seem to make any sense that setting PythonPath should caus
e t
he directory the Python*Handler directive is associated with to be ignored.
> Thus propose that PythonPath should be kept quite distinct from directorie
s in document tree for which Python*Handler is specified for and setting Pyt
honPath will would no longer cause directory Python*Handler directive is spe
cified for to be ignored.
> Overall, this should actually eliminate unexpected behaviour whereby user sets Pyt
honPath and then finds their modules in document tree can't be found. The only solut
ion to this with the old importer is to add the directories in the document tree exp
lic
itly to PythonPath directive.
> If there is some valid reason that the new importer should never look in the docum
ent tree for modules, then it would be better handled by some sort of PythonOption r
ather than it be a side effect of having used the PythonPath directive.

[ Post a follow-up to this message ]