bor.borygmus

Ian Bicking’s Python Paste jar of goods (and WebOb) is a testament to having a standardized web application protocol like WSGI. Rather than making the hard choice between starting with a framework like Django or starting from scratch, we can a mix and match libraries and build our fully-customized stack, all the while learning about Python web development and each other and our bodies and so on. For example, suppose Bill is on line three, screaming down your ear about choosing a WSGI development server by the end of this hour, dammit so everybody can deploy applications in a uniform way. Your first instinct is to, of course, grab madly at Paste Script, which takes a Paste Deploy configuration file and dutifully runs applications like nobody’s business.

So find a virtual environment and type: pip install PasteDeploy PasteScript.

The command-line interface to run a server is easy: paster serve start.ini where start.ini is our Paste Deploy configuration file. The docs for Paste Deploy are excellent, but let’s try and make a hello-word-type example and then take it a little further.

Start by finding a directory, something like ~/web/ and create ~/web/start.ini (below). We’ll start by turning on debug mode.

# file: start.ini
[DEFAULT]
debug = True

This is an INI configuration file so [DEFAULT] just marks a section where we force paster to read miscellaneous configuration variables. Up next, we want a tell paster to run a server

# file: start.ini (continued)
[server:main]
use  = egg:PasteScript#wsgiutils
host = localhost
port = 8080

Notice the colon in [server:main]. The (not necessarily fully correct) explanation I like to use is that Paste establishes lots of different namespaces; here we have “server”. Paste also uses “main” under each namespace to denote the default INI section. When you run paster serve, it will look for the default server under the “server” namespace, so we put this information in [server:main].

The “use” variable tells paster which Python module contains the server. Paths to Python modules are either a module that can be found on sys.path (anything you can import non-relatively) or an egg URI. Here we’ve used an egg URI because that’s how PasteScript is packaged. “#wsgiutils” is an entry point name within the PasteScript egg. If you crack open PasteScript’s setup.py file, you’ll see that this entry point corresponds to “paste.script.wsgiutils_server : run_server”, a function within the wsgiutils_server module.

Now we have everything we need to run a server.

# file: start.ini
[DEFAULT]
debug = True

[server:main]
use  = egg:PasteScript#wsgiutils
host = localhost
port = 8080

How does Paste Script find an application to run? It looks for a “main” subsection under lots of different namespaces. For example, to run one application, you would use the app namespace.

# file: start.ini (continued)
[app:main]
use = salmon:factory

Now Paste Script will look up a Python module named salmon, run app = salmon.factory(...), and expect app to be a WSGI application. Next time, we’ll take a stab at building a simple factory function.