[mod_python] Re: [modwsgi] mod_python publisher

Graham Dumpleton graham.dumpleton at gmail.com
Fri Apr 24 02:16:07 EDT 2009


2009/4/24 Matt Newville <matt.newville at gmail.com>:
>
> I'm looking to move from mod_python to mod_wsgi, and reading through
> the on-line documentation.
> 've been fairly happy with mod_python for my own scripts, but do
> appreciate that mod_wsgi is a better design and the future. I also
> want to update a MoinMoin wiki on the same server to using mod_wsgi,
> and am concerned about trying to have both mod_python and mod_wsgi
> running on the same server.

You can run mod_python and mod_wsgi on the same server, but in that
case certain features of mod_wsgi don't work as mod_python takes
control of initialising Python.

> Currently, I'm using mod_python's publisher handler for mapping url to
> python function name and arguments, and for basic authentication.  By
> themselves, the mod_python/publisher scripts I have  (ie, the code
> with "from mod_python import apache") are fairly small and simple and
> mostly manage a connection to larger python modules  for the
> application logic.
>
> It looks like there isn't an immediate replacement for these features
> within mod_wsgi, with the rationale given that such functionality is
> best handled elsewhere, perhaps in a larger framework.  Is this a
> correct reading?

It is only intended that mod_wsgi provide the low level gateway to the
server itself. This is in contrast to mod_python which provides the
low level gateway to the server, but also high level handlers.
Personally I think that mod_python did this was wrong, and the high
level handlers should have been separate. Problem it now causes is
that people don't want to give up mod_python because they are bound to
APIs which are part of the mod_python package. If those high level
handlers were separate, then there would have been a better chance
that they could have been rehosted on alternatives such as WSGI to
allow portability and migration away from mod_python.

> If so, what is the recommended path for those for
> whom the publisher handler was a good fit?  Are there recommended
> extensions that provide this functionality, or migration paths for
> code currently using mod_python publisher?

There was someone on this list who was trying to come up with a
package which offered compatibility with mod_python.publisher but such
that it could be hosted on WSGI instead. For my mind, although it may
aid in migrating away from mod_python, I don't believe that an exactly
compatible system is a good idea, as mod_python.publisher has various
aspects which I regard as being broken.

Although I have resisted before, partly due to lack of time, but also
because I had some bigger ideas in mind, I haven't pursued the idea of
creating a package which could be a stepping stone to get away from
mod_python and onto mod_wsgi instead. Since I am treading water a bit
at the moment working out what direction I am going to take with
mod_wsgi and whether I branch out and do something to improve fastcgi
hosting, maybe I can have a look at this a bit now.

As it turns out, most of the work is already done, as my Vampire
package for mod_python had a rewritten mod_python.publisher
equivalent. This fixes some of the problems in mod_python.publisher
and makes it more flexible, but still doesn't fix some of the things I
hate most about mod_python.publisher.

Anyway, I could take Vampire and repurpose it on top of WSGI and more
specifically mod_wsgi. The main thing I am missing to be able to do
that is a request object as obviously relied upon that from
mod_python. There are a couple of options there. First is to write my
own in order to avoid external dependencies, or use webob. There is
also Werkzeug, but it is much more than a request object so may be
bringing too much baggage.

For forms processing, would just fall back on cgi.FieldStorage, which
does mean a loss of a few mod_python features, albeit not often used.
The only other thing, but which wasn't really a part of
mod_python.publisher, is session support. In some sort of first
version one could ignore session support though. Another future area
to look at might be to bring across PSP support into the package.

The question is whether there is sufficient interest. In terms of
gauging that, have also cc'd this to mod_python list. If replying
please ensure you reply-all to both lists.

Do note that I wouldn't aim for compatibility as me being a pedantic
ass means I will not allow some of the stuff in mod_python.publisher
which I think is wrong. Obviously the request object isn't going to be
the same, although maybe one could have a mode where by you use a
request object wrapper to make it closer. As for the other stuff, that
may or may not affect many people. The particular area I have an issue
with in that respect is the really bad way mod_python.publisher deals
with trailing slashes. So, porting work would definitely be required.

So, is there any interest in a mod_python.publisher like package to
act as a easy migration path away from mod_python?

Graham



More information about the Mod_python mailing list