After some discussion on the TurboGears list about Paste, I started looking more closely into what it will take to get CherryPy to work with Paste. I had written a ticket on the matter some time ago, but progress there was slow, and it wasn't clear any resolution was going to come about anyway.

Ultimately I decided I could do it myself, even if I had to work against the CherryPy code a little bit, using threadlocal storage and some monkeypatching to make every CherryPy application think it was the root, and keep all the applications isolated and relocatable, as Paste wants them to be. I didn't read this discussion until I was well into the project, but that's probably just as well; the CherryPy developer there doesn't think threadlocal will work, but really we're coming at it from different directions; I just want one good API, I don't need for it to be the only API in CherryPy (I understand that they have to provide backward compatibility), and I don't need every CherryPy application to work, just the ones that do the Right Thing (where the Right Thing is still somewhat to be determined).

Anyway, the result is CherryPaste. With it you can write a config file like:

[app:main]
use = egg:CherryPaste
root_object = mypackage.rootobj:root

[server:main]
use = egg:Paste#http

And then serve that up with paster serve config.ini, as well as using that to potentially run multiple instances of the same app under different paths, or behind authentication, or with the Ajax debugger in Paste, or what-have-you. I don't have a lot of concrete experience with CherryPy and haven't tried this on many (well, any) large CherryPy applications, but I welcome feedback and experience reports, and hopefully some of the inevitable kinks can be worked out.

One of the misunderstandings that came up in the IRC discussion is about control. Part of the difficulty of CherryPaste is that CherryPy expects to have control of the process, and expects all CherryPy applications to register themselves centrally. So, why should CherryPy support Paste, isn't that just Paste saying that it should be at the top, that it is the more fundamental or proper abstraction?

No, that's not it at all. To work with Paste, an application or framework has to be well encapsulated. It has to be in its own package, it has to have an identifiable entry point, it has to have a clear concept of configuration. Then Paste can work with it. But Paste does not want to own the application (except perhaps at runtime, if it has been so configured). If the application provides a function supporting the paste.app_factory API, it doesn't have to do so exclusively. The application doesn't have to make Paste a requirement, and probably doesn't have to import anything from Paste.

So no, it's not that Paste wants to wrest control from CherryPy, it just needs CherryPy apps to have a clear boundary and not to demand control.

Next up... I'm not sure... create a similar Paste adaptation of Trac (where I could use it to experiment with installation) or Django (which would be more like CherryPaste, but probably requiring less cleverness)?