| Graham Dumpleton (JIRA) 2006-04-27, 6:52 am |
| [ http://issues.apache.org/jira/brows...action_12376144 ]
Graham Dumpleton commented on MODPYTHON-143:
--------------------------------------------
Going to be a pain and change the name of the PythonOption used to enable the new importer. The reason for this is that I am coming to the belief that making the new importer the default in mod_python 3.3 is probably not a good idea. Instead, mod_python 3
.3 when released should allow both to exist with the default being the old importer. When the user is ready, they can make a conscious decision to turn on the new importer and then modify their code if necessary to ensure it works.
The thinking here is that even though we may be able to produce some really good documentation that says how the new importer works, many aren't going to bother to check the documentation and ensure their code works first. Some may not even have a choice
given that it may be dictated by an ISP who makes the decision to install the new version. Also, you have projects like Django which rely on mod_python working in a certain way and there will probably be a lot of complaints if we dump out a new version of
mod_python which breaks it in some way. Depending on their release schedules they may not be in a position to release an updated version quickly. Thus we need to allow for a transition period where both options exist in an official release version, we ca
n't expect people to use the version out of subversion, or even final test tar balls.
As to turning on the new importer as the default, I would suggest that after mod_python 3.3 is out and bedded down, then we make a swap as to which is the default importer and release it as a new major version 4.0 so as to clearly signify that there are s
ufficient differences in how parts of the importer work. The old importer could be removed from the code in some future version after that.
This new major version could also be a good point to drop default support for old option names as talked about in MODPYTHON-127.
That all said, the new PythonOption I am going to use is:
mod_python.use_new_importer
The argument to the option would be as before. That is "*" for all interpreters, or a comma separated list of interpreters. The option will still need to be defined at global scope in main Apache configuration outside of all configuration containers.
On this basis I will now make some of the changes to the C code bits of mod_python which need to be made so that new importer works properly in all cases. Such code though will only be run when the above option lists the interpreter the request is executi
ng in. I'll also have to make the test harness suite be able to cope with running extra tests only for the new module importer, so how new importer is enabled in the test suite will change as well.
> Implement and integrate a new module importer.
> ----------------------------------------------
>
> Key: MODPYTHON-143
> URL: http://issues.apache.org/jira/browse/MODPYTHON-143
> Project: mod_python
> Type: Task
> Components: importer
> Versions: 3.2.8
> Reporter: Graham Dumpleton
> Assignee: 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 y
et been decided.
> More details and announcements at the appropriate time.
|