The universal feedback I've received on paste attempts to define Paste
is that no one got it. My fault. Anyway, since then I've started
thinking differently about the composition of Paste and split it up in
a different way. So, yet again, I try to explain what Paste is:
Paste is just a name
OK, that's a dodge. Paste is stuff I think is important and
underdeveloped elsewhere. But I can be more specific about the pieces...
Paste Script is a pluggable
command-line script (called paster). Using plugins you can add new commands
like paster my-command to it, either adding them globally
or framework-local. "Framework" doesn't necessarily mean web
framework, it can mean anything, including ad hoc commands specific to
a project.
Paste Script provides two commands by default:
- paster create is a command that creates or updates projects
according to some layout template. The templates themselves are
also pluggable. This is essentially the start-project command
already present in many recent frameworks.
- paster serve is a command that loads Paste Deploy configuration
files (more about that later) and serves them up.
Paste Deploy is a pluggable
configuration-file loader for web applications and servers.
The "plugins" that you provide to Paste Deploy are actually
factories for applications and servers. The
configuration file will indicate what factory you want to use, and
then the arguments to send to the factory. This is to say, the
application and its configuration.
Factories themselves can be other configuration files, or Python Egg
entry points. That's part of setuptools, not Paste, so
I won't describe it here. But it's something good to understand. Ben
Bangert had a post describing setuptools in the context of Paste,
which might be helpful.
Paste Deploy is pretty simple when you get down to it -- it's just
factories, passing in configuration data, and returning a WSGI app.
What's a WSGI app? Your framework should be able to give you one of
those -- if you are just writing an application, you shouldn't have to
know about the details of WSGI. If your framework doesn't support
WSGI, then you should ask the framework authors to fix that.
Paste Deploy does implicitly encourage some specific practices. One
is that you keep your configuration separate from your application.
Hopefully the benefits are obvious, but in practice this is not the
norm in a lot of current frameworks. Also, there are other tools
(in Paste core which I talk about next) which work better if your
application is well encapsulated and obeys the WSGI spec and uses WSGI
semantics (one common issue is respecting and properly adjusting SCRIPT_NAME and
PATH_INFO, though other ones come up). These again are framework issues, but ones that several
frameworks do not currently get right.
Another feature of a Paste-Deploy-enabled application is that it will
have a simple factory that takes specific arguments. So while it
makes the application configurable, it also makes it really easy to
invoke the application programmatically. This means that it should be
easy to create applications that embed each other, by delegating some
incoming requests to the embedded application.
Maybe I'll do a screencast on Paste Deploy sometime soon. It's best
feature, IMHO, is that it's actually quite simple, and it maps to
simple Python function invocation.
So there's another package called just "Paste". It has a bunch of
tools. These tools are "dead", in that they don't magically appear in
your environment, you aren't forced to use them, and they mostly
aren't required in order to work with each other. The full list is
described on the features page.
You don't have to use any of these. Most of them are of more
interest to a framework developer than an application programmer, and
they are best used when adopted into a framework. If you have an ad
hoc framework then you might be interested; if you aren't
using some other framework, you've likely built an ad hoc framework whether you meant to
or not. It's hard to program directly against CGI, mod_python, or
some other low-level system without somehow creating a framework.
All the Paste parts use WSGI, because they are all intended to be framework
neutral, and there is no "framework neutral" in Python web programming for much
of this functionality except for WSGI.
A number of the tools are "WSGI middleware", which means they wrap
WSGI applications. What's a WSGI application? Remember: if you
aren't developing a framework you shouldn't need to know, except to
know that your framework creates a WSGI application for you. But,
back to middleware -- it means that a request goes through the
middleware (which can modify it) and the response goes out through the
middleware (which can also modify the response). This is how things
like exception catching are implemented:
- The exception catcher wraps your app in try:except:
- If everything goes fine, it passed the request through, and passes
the response out without modification.
- If your application raises an exception, it turns this into an
exception report, and depending on configuration may email it to
someone or just display it in the browser.
But, this is a framework concern. If you like the exception
catching middleware (because it's cool), then your framework should
adopt it, or at least allow for it, and it should pass through
configuration to that code. It's probably not something that a modest
application developer will concern themselves with. Of course this is
open source, so everyone can be a framework contributor. In the end,
if you use lots of these Paste tools you can write a framework from
scratch with very little code. Your framework will be all about
creating an aesthetically cohesive wrapper around the tools; Paste
isn't a framework, WSGI isn't a framework, they are just agreements,
and tools that utilize those agreements.
There are also some tools in Paste that are useful with Paste Deploy,
like something to map requests to subapplications based on URL
prefixes. It should be possible to apply these to a well-encapsulated
WSGI application without problem, and so these are "deployer"
concerns, not application author or framework developer concerns.
So that's what Paste is. Maybe it makes more sense this time.
One thing I'll note is that I think Paste Deploy is the most important
of these pieces. The other's are convenient, they might make your
development easier, but if they don't then you shouldn't use them.
But making your application available through Paste Deploy makes life
easier for everything that wants to use your application. If, say,
CatWalk was available through
Paste Deploy, then I could embed it into any application I write, even
if I'm not using TurboGears. If PyFileServer was Paste Deploy
enabled, then I could include a WebDAV server with any app, etc.
Paste Deploy is what starts to address Python's flaws compared to PHP.