Python, WSGI, legacy web application

[Ben Finney]

Howdy all,

I'm working on a web application that is starting to gain a lot of
back-end code written in Python. However, all the current interface
code is written in legacy PHP. I'd like to slowly introduce new
features as Python WSGI programs.

Is it possible to write a Python WSGI program that talks to a PHP
program as its "back end"? Where can I find out how to do this,
preferably with examples?

The ideal here is to keep all the existing code as is, but write
little or no new PHP code. Instead, iteratively change the interface,
replacing pieces of the monolithic legacy PHP interface with modular
WSGI programs over time.

--
\ "I don't know anything about music. In my line you don't have |
`\ to." -- Elvis Aaron Presley (1935-1977) |
_o__) |
Ben Finney

[Graham Dumpleton]

Ben Finney wrote:

Howdy all,

I'm working on a web application that is starting to gain a lot of
back-end code written in Python. However, all the current interface
code is written in legacy PHP. I'd like to slowly introduce new
features as Python WSGI programs.

Is it possible to write a Python WSGI program that talks to a PHP
program as its "back end"? Where can I find out how to do this,
preferably with examples?

The ideal here is to keep all the existing code as is, but write
little or no new PHP code. Instead, iteratively change the interface,
replacing pieces of the monolithic legacy PHP interface with modular
WSGI programs over time.

Look at mod_python for Apache. If you use it correctly you can on a
page by page basis as need be, replace the existing PHP pages with
equivalents written using Python. You could do this by programming
right at the level of mod_python, or again, if done right by using WSGI
on top of mod_python. If you need to maintain compatibility of URLs,
you could even do things so that even though URLs use .php, that it
maps to Python code underneath, thus easing any transition.

If you are interested in this path, the mod_python mailing list may be
a good place to go to discuss the mod_python aspects of this. The
mod_python mailing list details are on the mod_python web site at
www.modpython.org.
Graham

[ToddG]

Ben Finney wrote:

Is it possible to write a Python WSGI program that talks to a PHP
program as its "back end"? Where can I find out how to do this,
preferably with examples?

Perhaps:

http://pythonpaste.org/wphp/
http://blog.ianbicking.org/2006-wphp.html

[Ben Finney]

"ToddG" <td*****@gmail.comwrites:

Ben Finney wrote:

Is it possible to write a Python WSGI program that talks to a
PHP program as its "back end"? Where can I find out how to do
this, preferably with examples?

Perhaps:

http://pythonpaste.org/wphp/
http://blog.ianbicking.org/2006-wphp.html

Looks good. Can anyone here tell any stories about using this for its
stated purpose?

Where would be the best place to ask further questions on this?

--
\ "Two paradoxes are better than one; they may even suggest a |
`\ solution." -- Edward Teller |
_o__) |
Ben Finney

[Ben Finney]

"Graham Dumpleton" <gr*****@dscpl.com.auwrites:

Look at mod_python for Apache. If you use it correctly you can on a
page by page basis as need be, replace the existing PHP pages with
equivalents written using Python. You could do this by programming
right at the level of mod_python, or again, if done right by using
WSGI on top of mod_python. If you need to maintain compatibility of
URLs, you could even do things so that even though URLs use .php,
that it maps to Python code underneath, thus easing any transition.

I was under the impression that WSGI in mod_python was a rather kludgy
way to do WSGI, but I don't know what the alternatives are. CGI?
Python http server (e.g. CherryPy)? Something else?

--
\ "Compulsory unification of opinion achieves only the unanimity |
`\ of the graveyard." -- Justice Roberts in 319 U.S. 624 (1943) |
_o__) |
Ben Finney

[Rob De Almeida]

Ben Finney wrote:

I was under the impression that WSGI in mod_python was a rather kludgy
way to do WSGI, but I don't know what the alternatives are. CGI?
Python http server (e.g. CherryPy)? Something else?

You can use FastCGI or SCGI too, with Apache, lighttpd or Cherokee. I
have a short description of different ways to run a WSGI app here:

http://pydap.org/docs/server.html

Though it's focused on a specific WSGI app I wrote it uses Paste
Deploy, so you can generalize it easily.

--Rob

[Paul Boddie]

Rob De Almeida wrote:

Ben Finney wrote:

I was under the impression that WSGI in mod_python was a rather kludgy
way to do WSGI, but I don't know what the alternatives are. CGI?
Python http server (e.g. CherryPy)? Something else?

You can use FastCGI or SCGI too, with Apache, lighttpd or Cherokee.

I think the motivation behind suggesting an Apache solution was that
you'd be able to migrate the PHP resources you already have running in
Apache (I assume, since PHP can run in other places these days) to
mod_python whilst staying within the Apache environment, rather than
having to maintain a number of different environments at the same time.
In other words, you'd write your replacement resources using WSGI (or
whatever) on mod_python (for performance), CGI (for relative
simplicity), or some other connection technology, and then it'd just be
a matter of changing the various directives and having Apache figure it
out.

I know some people advocate proxying to a variety of backend servers,
and the Web obviously lends itself to flexible architectures in this
respect, but there are fairly good reasons for keeping the component
count low.

Paul

[Graham Dumpleton]

Paul Boddie wrote:

Rob De Almeida wrote:

Ben Finney wrote:

I was under the impression that WSGI in mod_python was a rather kludgy
way to do WSGI, but I don't know what the alternatives are. CGI?
Python http server (e.g. CherryPy)? Something else?

You can use FastCGI or SCGI too, with Apache, lighttpd or Cherokee.

I think the motivation behind suggesting an Apache solution was that
you'd be able to migrate the PHP resources you already have running in
Apache (I assume, since PHP can run in other places these days) to
mod_python whilst staying within the Apache environment, rather than
having to maintain a number of different environments at the same time.
In other words, you'd write your replacement resources using WSGI (or
whatever) on mod_python (for performance), CGI (for relative
simplicity), or some other connection technology, and then it'd just be
a matter of changing the various directives and having Apache figure it
out.

Correct.

As example, imagine you have written a mod_python handler which itself
interprets how to map a URL to something to implement the URL. This
might map to a WSGI application or to some system of basic mod_python
handlers.

Within the .htaccess file of the directory where all your PHP files
live you could then write:

PythonHandler myphppagereplacementhandler | .php

At this point nothing will happen, but then one could do the following:

<Files index.php>
SetHandler mod_python
</Files>

For the one page called 'index.php' the mod_python handler would be
called instead of PHP. As a Python equivalent for each PHP page is
written, just need to trigger the mod_python handler to be used by
using the Files directive.

One could also have different handlers for each page and use Apache to
make the selection if wanted to:

<Files index.php>
SetHandler mod_python
PythonHandler myphppagereplacementshandler::index
</Files>

Now I am sure that some will say it looks messy, but as far as trying
to do a progressive replacement of pages and maintain URLs, it is
probably the quickest way. It should be said that any progressive
migration like this is likely to be a bit messy.

Don't like this, then another way using Apache might be to use
mod_rewrite to remap URLs to new URLs which use Python code. Using
mod_rewrite can be a pain though. Yet another way may be to use
mod_proxy to selectively forward URLs through to a separate back end
web server if you are Apache phobic and want to use a web server
written in pure Python.

Overall, Apache/mod_python has a lot to offer, but from what I have
seen most Python web frameworks simply uses it as a jumping off point
and not much else.

Graham