History and Vision For the PythonWeb.org Project

Python Web Modules

PythonWeb.org code was initially based in November 2003 on the Lemon modules and provided a complete set of tools for writing CGI scripts in Python. There were already a number of frameworks around including Webware and Zope but nothing provided the tools needed to quickly write CGI scripts in Python the way you could in Perl. Included was software for accessing SQL databases in a database independant fashion, auth and session handling, email sending, form handling, templating and much more. The PythonWeb.org maxim was:

"It is better to have a flexible module that can be used intuitively than 
an all-singing, all-dancing framework that no-one can be bothered to learn."

The web modules as they became known were very popular and are used worldwide by various Python web developers. Even someone at NASA's JPL has worked with the software.

Web Server Gateway Interface

In 2004 along came PEP 333, the Web Server Gateway Interface (abbreviated WSGI) which was developed on the Python Web-SIG mailing list by Philip J Eby. The PEP described a way in which different WSGI applications, middleware components, servers and gateways could interact in a defined way. By implementing the specification code developed by the various competing web frameworks could be used together.

The web modules were refactored in January 2005 so that as well as working in a CGI environment they fully supported the Web Server Gateway Interface specification.

The Recent Past

Over time the codebase for the web modules began to grow rather large. Various components such as the web.database module became useful in their own right. It was therefore decided on the PythonWeb.org mailing list that the code should be refactored into smaller components, each of which could be maintained induvidually.

Since some of the modules that depended on each other a package management system named carton to be based on the eggs format was begun after a couple of emails on the distutils-SIG. Soon after eggs began taking on extra functionality and sprouted new projects. The original eggs project now includes setuptools and easy_install and now form a powerful package management system which can automatically download packages from the Python Package Index. The system can now be likened to jar files from Java, CPAN from Perl and Gems from Ruby.

It also became obvious that a more standard way of using the web modules could cut down on the duplication of code for each project. Projects like Ruby on Rails had shown how popular simple to use web frameworks could be.

Current Situation

The WSGI is now fairly mature and work is being done to provide standardisation in the way WSGI applications are deployed. In order to make rapid web application development possible and to reduce the amount of code uplicated by each project Bricks was started to provide a lightweight framework for developing applications using the Python web modules.

Eggs now support a feature called entry_points which allow you to specify classes in your code which can act as plugins. This means that very soon it will be possible to write a config file similar to the one below to be used as a CGI script and automatically have all required libraries downloaded when you execute the script. Web programming really can't get any simpler:

#!python wsgi_run_CGI.py

[caseChanger from web==0.5 ]
newCase = 'lower'

[testApplication from web==0.5]
message = 'Hello World!'

So we are currently in a position where an application deployment can be written in a few lines, packages can be automatically downloaded and scripts, examples and package data can be included in the distributed eggs.

The final feature required is automatic generation of documentation for all the eggs. At the moment the docutils project looks the most promising for acheiving this but isn't currently finished. In the interim the pigeon project has been started to fulfil this task (this file itself is generated using pigeon).

The 0.6.0 releases of all the PythonWeb.org components including bricks and pigeon represent the end of the separation of the old codebase. Whilst setuptools is still in active development and until proper documentation is written they should be considered alpha software.

We are very quickly moving towards a situation where all all Python web frameworks can operate together in a standard way with automatic library installation and componet-based design as we enter a new era in the development of web software with Python.

At the forefront of the implementations will be Bricks and it is envisioned that Bricks will form the basis for the majority of projects that would previously have used the python web modules code.

Downloading

A SVN tarball is available from http://www.pythonweb.org/snapshots/ for those who prefer source distributions. The individual eggs are temporarily available from http://www.pythonweb.org/doc/pythonweb/release/

Installing

To install the components as they stand you will need Python 2.4 and the latest version of Easy Install

Then at the command line type:

> C:\Python24\Scripts\easy_install.py pythonweb

Replacing C:\Python24\Scripts\ with the path to the easy_install.py script. This command will automatically download and install all the PythonWeb.org components. (For more advanced options see the Easy Install documentation).

To install just an induvidual component replace pythonweb with the name of the module you wish to install. eg:

> C:\Python24\Scripts\easy_install.py database

will install the latest version of the database module and all its dependencies.

If you run into difficulties just download the egg files manually, rename them .zip and place the relevant directories in your Python site-packages directory. Rememeber, all this is alpha so don't be too suprised if it doesn't work!