Graham Dumpleton wrote: > > On 13/08/2006, at 12:35 AM, Jim Gallacher wrote: > >> Graham, >> >> In your JIRA cleanup session you made the comment a number of times that >> the new importer is not likely to be the default in 3.3. I'm just >> wondering why it can't be the default, with the old importer as an >> option? Maybe: >> >> PythonOption mod_python.legacy.importer * >> >> If we were to do this we'd likely want a longer 3.3 beta test period, >> but if it takes care of the ongoing module import issues it might be >> worth it. > > I wasn't looking at it as being the default as I only know of one person > so far > who has been even trying to use it, thus feedback on it has been very > limited. It may be that the lack of negative feedback means that there > are no > problems in the code, but it would help to get some positive feedback from > anyone who is using it on real world code examples even if only in a > development setup, that it is working okay. That way I would feel more > comfortable about making it the default.
I've had it turned on on my development machine since April, without problems. However the stuff I'm doing is pretty plain vanilla and I have generally designed things to avoid the problems seen in the old (3.1) importer, so my experience may not be the best test. > By making it the default and therefore a first class citizen and not just > the hanger on it is now, then also opens up the possibility of introducing > some new directives to control it, rather than using PythonOption for > some things. > > For example, if one is to introduce a feature whereby a global search path > can be specified for modules like PythonPath does for sys.path, then I > would > prefer it to be a directive, perhaps calling it PythonModulePath. The > reason > for making it a directive is that with the new directive I proposed in > recent > JIRA issue, one could say: > > PythonModulePath '["/some/path"]' > PythonAllowOverride -ModulePath > > This makes how to configure it more visible and at the same time allows > the main Apache configuration to set where extra modules can be found > but then prohibit a user from changing it. > > One slight problem with prohibiting overrides, is that even for directives, > a user can get in and modify the table object returned by req.get_config() > which could screw things up. To fix that, I think perhaps that the table > object > should be able to be created as read only so that handlers can't modify it. > As with introducing PythonAllowOverride in the first place, making it so > the config table object is read only is another step in making it > possible to > restrict what can be done in handlers thereby making it perhaps a bit > friendlier to ISPs who want to make mod_python available and know that > one user can't screw up another users stuff. I think this is a worthy goal. I'd also like to come up with a fix for the shared mutexes. It is just not right that one user can deadlock the server by grabbing all the locks and never releasing them. > Anyway, if we can make a decision that we will make new importer the > default in 3.3 that would be great and would allow me to progress with > other > ideas. When I have raised this question before though, never really got any > responses or agreement on whether to proceed with making it the default. > > Graham I think part of the problem is that you are the only person that has taken the time to think through the import mechanism. It makes it difficult for the rest of us when we haven't made the effort to understand the deep magic. It's unfair to put that kind of pressure on you, but to some extent that is a result of a fairly small developer community. Is the importer change big enough to warrant a jump to 4.0, in order to indicate that this is a *major* change? Either way (3.3 or 4.0 as the next release) I'm in favour of turning on the new importer by default. As long as users have the option of falling back to the old importer if things go pear-shaped I think we'll be OK. Not turning it on by default now means that won't happen for another year (if past history for releases is any idication). If it's just optional in 3.3 my guess is most users *won't* turn it on, so we really won't be that much further ahead. If and when we do turn it on by default we should make a much more vigorous attempt to solicit testing feedback from application developers, beyond getting people to just run the unit tests. Jim
