quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel J. Popowich" <dpopow...@comcast.net>
Subject Re: sys.path and htaccess change?
Date Fri, 18 May 2007 15:10:26 GMT
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

Mime
View raw message