[ http://issues.apache.org/jira/browse/MODPYTHON-154?page=comments#action_12375851 ]
Graham Dumpleton commented on MODPYTHON-154: -------------------------------------------- The new module importer was already always looking in Python*Handler directory 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()" function 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_module()" in the handler root directory will look at that directory anyway, by tracking back and see where the import is being done from, one questions whether it should look in the handler root directory at all in cases where the import is from a sub directory, 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 modules used by two web applications with different handler roots but which wrongly are not running in distinct interpreters. If both handler roots had a config module in them and the common code wanted to import the config module, whichever handler root was accessed first would have its config module loaded. When the other web application 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 import was being done from within the handler root directory itself. Alternatively, a slight variation on this could be done. That is, if the location 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 down from outside of the directory tree though, it should not look back at that handler root. If a change is made, there is a danger that some old code would no longer function. Would suggest that to cope with that a PythonOption be used to enable the old questionable behaviour. The option though would only exist though so that code could run in the first instance prior to its structure being redone to work in a more predictable 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 physical > 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 > importer 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 cause the directory the Python*Handler > directive is associated with to be ignored. > Thus propose that PythonPath should be kept quite distinct from directories > in document tree for which Python*Handler is specified for and setting > PythonPath will would no longer cause directory Python*Handler directive is > specified for to be ignored. > Overall, this should actually eliminate unexpected behaviour whereby user > sets PythonPath and then finds their modules in document tree can't be found. > The only solution to this with the old importer is to add the directories in > the document tree explicitly to PythonPath directive. > If there is some valid reason that the new importer should never look in the > document tree for modules, then it would be better handled by some sort of > PythonOption rather than it be a side effect of having used the PythonPath > directive. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
