I spent way more time than I planned or wanted to spend on CherryPaste today, mostly trying to get Catwalk to work correctly.
First, CherryPy's WSGI application doesn't use SCRIPT_NAME like it should. After getting a less than enthusiastic response on that ticket, I thought I would just not bother pursuing that and fix it myself. CherryPaste could then be seen simply as the valid-to-spec WSGI application for CherryPy. That ended up being a pain in the butt. The VirtualPathFilter recipe I built off of is just a silly hack, frankly, despite the fact that it's a likely part of any realistic deployment. The WSGI environment is thrown away, so if you planned to pass information through WSGI into the CherryPy request you can't. I haven't looked very hard, but I haven't yet found the way to turn off CherryPy's catching of exceptions (which I want because Paste has a better exception handler). CherryPy eats exceptions from some filter methods.
This all to get Catwalk to run under something besides the root path. Then I realize CatWalk has entirely hardcoded URLs. That's just silly. turbogears.view.stdvars creates dynamic values that it should be using; that was an easy enough change. Except TurboGears bases those values off something calculated at server startup, and stores it in a module global. So I have to patch in a threadlocal value that poses as a string. Lastly Catwalk patches the configuration to add static paths when you access the index page; but since I'm keeping configuration information isolated to each request that doesn't work. So I have to add a specific hack to the Catwalk entry point to fix up the configuration on each request.
In the end it all works, at least for this one case. But damn. This is not what I want to be working on. I feel like I'm just cleaning up other people's shit. I have enough shit of my own that needs cleaning up.
It's not like this is Paste-specific stuff. No one knows how to do this stuff in CherryPy. No one seems to have any authoritative answer on how you deploy these apps -- how you move between servers, how you change the application root, how you put apps together into a single server. Everything is ad hoc stuff that just barely works for one app on one server. It's all "recipes". Recipes are often just stuff that no one cares enough about to do right. This is too central to what CherryPy is supposed to be doing to be a recipe.
It occurs to me that TurboGears was extracted from an application that runs on the local machine. In that case none of these issues would have been apparent. But that's not similar to how people are actually using TG. I think these shaky underpinnings are risky for the project.
Catwalk does all sorts of bad things, like bare except clauses... The style is also very sloppy and inconsistent with PEP-8. It definitely isn't worth my time to fix, though, especially because it's not technically broken. Hopefully the developer will fix those bad habits with more practice.
Yeah, there's a number of things. But these are all mostly easy bugs. The template was... well, very peculiar that it hadn't been fixed. But certainly not hard to fix. Doing it right actually was hard, but that wasn't Catwalk's fault.
# Ian Bicking
> I haven't yet found the way to turn off CherryPy's catching of exceptions
That feature was added to CP 2.2 on Dec 27, 2005 in http://www.cherrypy.org/changeset/884. Set the config entry "server.throw_errors" to True.
Doh, I saw that, but I was setting the environment (instead of the configuration) to have server.throw_errors (which doesn't do anything). So CherryPaste should handle that now, and Paste exceptions should be usable around a CherryPy app.
# Ian Bicking
This is a common problem with cherrypy. there is now easy way of distributing a cherrypy application. And there is also no easy way to setup more than one cherrypy application on a server.
I've hacked up something that allows you to distribute cherrypy applications as eggs.
You can see the source at http://bwinton.latte.ca/Programming/cherryPy/ and the (not entirely working at this point for some reason, but used to work before) result at http://cherrypy.latte.ca/
(Yes, I know my server is down. I'll reboot my POS-brand router when I get home.)
Surely the big jaw-opener for CherryPy (or was it TurboGears?) was that barely-reported security hole that came up the other day. Less time on the hype and more on the software is the answer there, I think.
# The Badger
I also find catwalk's assumption that it's at the root path annoying, could the changes you made (the hard-coded url bits - obviously the WSGI bits don't apply) be submitted as a patch to TurboGears? Seems like a waste not to get it in there!
# anonymous
Yeah, I was planning to that -- Trac just happened to be down while I was doing this stuff.
# Ian Bicking
The necessary changes to Catwalk have now been committed.
# Ian Bicking
I've responded here: http://groups.google.com/group/cherrypy-users/browse_thread/thread/5f35e3497d730219