Jorey Bump writes: > Graham Dumpleton wrote: > > > The whole point of the changes which were made was to draw a well > > defined line between the code modules used in the web application and > > which reside in the document tree, or other specially specified areas > > by way of mod_python module importer path, and the standard Python > > sys.path locations. > > I think it's important to emphasize this point.
I don't have a problem with making a distinction, either. But I do have a problem with behaviour like this changing (handler directory no longer in sys.path) between minor upgrades. I probably have users downloading mpservlets, launching the tutorial, saying to themselves %#&@% piece of crap and moving on. > > That there was no distinction before is what > > caused all the issues with same named modules, loading of incorrect > > modules, reloading of modules which shouldn't be reloaded etc etc. > > And it's also important to point out that discussion of these problems > has become virtually nonexistent, whereas they used to dominate the list. It was never clear to me that the problem was mod_python, but rather publisher. The novices coming to mod_python would go to the tutorial which pointed them to publisher and so in the mind of the novice: mod_python == publisher is True. As they used publisher and pushed its boundaries, importing issues became a major problem. I think it worthy to note that the swarm of importing questions rarely (ever?) involved psp or mpservlets, which had their own importers. > > I remember when I first brought up this idea of 'import' working in > > magic ways so things would just work as one expected, that there were > > at least one person who thought it was a silly idea. > > That could well have been me. I viewed the issues as limitations, not > necessarily weaknesses, and knew what to expect once I refined my > approach. I was worried that changing the module importer could > introduce more issues and force users to include proprietary mod_python > code in their modules (excluding handlers, which are a special case). I don't have a problem with mod_python tweaking import. It's well known by python programmers (well, those who've been around awhile) that this is a tool at their disposal. I would just like to see it more **boldly** stated that it does. This knowledge may not make a difference to those who are using mod_python indirectly (those coming to it to use publisher, psp, mpservlets, vampire, etc.), but to those who write and maintain these handlers, it's HUGE. > Since I keep nearly all of my code outside of the document tree, I'm not > necessarily the target beneficiary of the changes made to the module > importer. But it has eliminated namespace collisions and reloading > issues in my frontends, so I benefit from the improvements and agree > that things are much better. 3.3 is easily my favorite version of > mod_python. I have found it a very powerful tool to be able to co-locate mps files with regular python modules. In fact, I find it odd to separate them: why put part of my applications code in one place and install the rest in another? Mpservlets does not allow files beginning with an underscore to be requested (generates a 403 response), so it's great to be able to place modules (eg, named _utilities.py) in the same directory as the front-end mps files. The developer doesn't have to worry about installing pieces of their package in site-packages or some such place, so packaging is much easier. A prime example is the mpservlets tutorial: everything is in one directory, very self-contained and easy to install. > > All I can suggest is you try it by starting with the changes to > > mpservlets as I described and then simply see if your existing > > applications which use mpservlets still work. Since the release we > > have only had a few people even be slightly affected by the > > differences, plus all the complaints we used to get about problems > > with the old importer have pretty well vanished. > > I'm lucky enough that none of my applications are publicly > distributed... Yes, you are. :-) > Daniel's in a rough spot, though, because he has to support all of the > versions of mod_python that are out there (within reason). While we may > find it trivial, the average user is unlikely to upgrade from a version > included in the platform distribution (which could be dangerous if other > packages were tweaked to rely on the state of mod_python when it was > packaged). It sounds like he will still need to include his old caching > system and disable it when it's not needed. Hopefully, this won't be too > hard or require a fork. I don't think there's really a problem with my importer co-existing with 3.3 (although it would make sense for me to piggyback off mod_python's, just like I do for sessions, cookies, etc., so I *do* want to use the 3.3 importer at some point). I just need to figure out how to fix the python module/mps file co-location problem in an elegant way. Dan
