[ http://issues.apache.org/jira/browse/MODPYTHON-143?page=comments#action_12427684 ] Graham Dumpleton commented on MODPYTHON-143: --------------------------------------------
This issue is basically complete and is just lacking some documentation. The name of the PythonOption setting was never changed and is still mod_python.future.importer. As stated before, to enable use of new importer for all Python interpreter instances, in other words for everything, will be necessary to specify: PythonOption mod_python.future.importer * To enable use of the new importer for selected Python interpreter instances, instead of "*" a comma separated list of interpreter names can be specified. Thus, to enable for a single interpreter called "testing-1", use: PythonOption mod_python.future.importer testing-1 Or for both "testing-1" and "testing-2" interpreters, use: PythonOption mod_python.future.importer testing-1,testing-2 In all cases, the PythonOption must be in the main Apache configuration files outside of any VirtualHost, Directory, Files or Location directives. It still looks like use of this new importer will be optional in mod_python 3.3 and enabled as default only in some subsequent version. > Implement and integrate a new module importer. > ---------------------------------------------- > > Key: MODPYTHON-143 > URL: http://issues.apache.org/jira/browse/MODPYTHON-143 > Project: mod_python > Issue Type: Task > Components: importer > Affects Versions: 3.2.8 > Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > > This is an overall task to cover the issue of rectifying the various module > importer issues by replacing it with a new implementation. A description of > the various problems can be found in: > http://www.dscpl.com.au/articles/modpython-003.html > Separate issues had already been created for some of the specific problems. > These issues will now be linked to this problem and thus marked as being > dependent on this issue. > In other words, replacing the module importer will solve a number of number > issues. Rather than try and keep up to date all the separate issues, all > information about the replacement will be put against this issue instead. > Note that there are also some issues which are not directly related to the > module importer but which will be made dependent on this issue because it is > easier to fix the issue as part of the rewrite of the module importer and top > level handler dispatch mechanism than it is to address it as a distinct item. > In respect of what impacts the new module importer implementation may have > and how it is used may change, this will be documented in the following > document for the time being: > http://www.dscpl.com.au/articles/modpython-007.html > Note that this document is a work in progress. It is dense reading and > assumes you know a bit about the current module importer and its problems. > Any significant issues raised by this document can be added here as a > comment, or if a general dicussion of a topic is needed, raise the issue on > the mod_python developers mailing list. > A possible new implementation for the module importer is basically ready for > testing and experimentation. The intent is to push it into the mod_python > source tree, but for its use to be optional. > If wanting to enable it for a specific Python interpreter, the PythonImport > directive would be used: > PythonImport mod_python.future.importer mytestinterpreter > If wanting to enable it for all Python interpreters, a PythonOption directive > would be used at global scope within the Apache configuration. Ie., outside > of all Location, Directory or Files container directives. The exact option > name to be used hasn't yet been decided. > More details and announcements at the appropriate time. -- 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
