Pylons

At long last, we’ve finally launched the Stanford IPLC website that I’ve been working on for the past year. It’s quite nice to finally have something out there that I can show people, though I know its definitely more of a niche area of interest, as ... [More] not everyone is probably as interested in intellectual property litigation as I am. :) This site is running Pylons of course, with various other technologies I’m unable to disclose powering the back-end. Note that signing up requires a valid e-mail address as e-mail confirmations are sent out to them. For those that are keen to keep up on what’s going on with patent litigation, hopefully our website can help out. [Less]

I’ll be giving a talk tonight about WSGI, making apps using it, and Pylons tonight in San Francisco. If you live in the Bay Area and have been wanting to learn more about some of the packages utilizing WSGI, as well as Pylons, RSVP soon as they’d ... [More] like to get some numbers for food. Here’s the meetup event page for the talk. This is one of the longer talks I’ve given, so I should actually have enough time to cover the topics (WSGI, WSGI Middleware, making low-level WSGI apps with WebOb, making small WSGI stacks, and Pylons) in good detail, as well as some demonstrations. [Less]

Python 2.6 came out yesterday, so I figured I might as well see if Pylons works on it. Pylons already has a set of buildbots that builds Pylons along with some of its dependencies, so it was fairly trivial to add another builder to verify things ran ... [More] swimmingly on Python 2.6. Unfortunately, as one can see looking at the build results, things weren’t so great. It appears that nose had a Python 2.6 incompatibility which is used to run all the various Pylons tests, meaning that they all failed so far mainly because the testing tool was Python 2.6 incompatible. Making Buildbot nicer While I wait for the new nose to be released, I did at least discover a little bug in my new webapp that provides a nicer view of the buildbot result set. I’ve been fairly displeased with the lack of conciseness of buildbot’s waterfall display for awhile, and noticed that if only buildbot had a few more xmlrpc methods then it’d be trivial to build my own more kind interface. I should note that the waterfall display isn’t totally horrible, the Django folks spiced their builders up with some CSS work…. which reminds me, it isn’t looking very good for those running on trunk at the moment. ;) So after making my own little buildbot fork to add some additional custom xmlrpc methods to, I’ve come up with my own buildbot status viewer. I’m sure a more talented designer could spice it up even more, but it gives me the pertinent data I’m interested in without all the boring “builder connected, builder took a vacation” messages that cloud up the waterfall. Also, rather than displaying the cryptic “shell_21 failed” messages, it actually uses the names I attached, and shows them quite clearly for the last build. I’ll submit some patches for these xmlrpc additions to buildbot when I get the time, but right now I mainly needed the Mercurial 1.0 hook compatibility (that was broken for quite awhile in buildbot), and a fairly specific set of information from the xmlrpc methods that I wasn’t sure others would want. I’m looking forward to trying out the new nose so that I can hopefully verify Pylons is good to go on Python 2.6 as Phil Jenvey’s been working tirelessly on patches to Beaker and other dependencies to make them 2.6 compatible. Any suggestions or thoughts on improving my buildbot viewer are welcome. :) [Less]

Pylons 0.9.7rc1 was released a week ago, unfortunately I haven’t had time to actually blog it so better late than never. This is a big step towards the 0.9.7 release, and contains some major changes over 0.9.6 while still retaining a huge degree of ... [More] backwards compatibility. At this point, the thing I get asked the most is: When will Pylons 0.9.7 be released? So the short answer, when the new website and docs are ready. We’re going to a lot of effort to totally eradicate that old mantra that “Pylons has no docs”, and we’re doing it big. Most of the docs have already been updated, revamped, and moved to the new Sphinx doc tool (Take a look at the new Pylons docs). The new website is nearing completion as well, and for those using the 0.9.7 release candidate, when posting a traceback you’ll get a link to it thats on the new beta website. Until then, 0.9.7 is feature-frozen and newer RC’s up to 0.9.7 are bug-fix only. New Features Pylons gets the substantial amount of its feature-set from the other Python libraries it uses, and here’s some of the new things these libraries have brought Pylons users: Moved to WebOb from Paste for the Request and Response objects WebHelpers 0.6 (previous was 0.4) This is a huge update, including safely escaped HTML builders, a literal object to mark strings as safe (vs unsafe) for use in templating languages, and a move away from all the old ported Rails helpers to new ones that in many cases have more features with less bugginess Routes 1.9, with minimization turned off. This helps for more predictable route generation and matching which confused many, and in some cases led to hard-to-debug routes being created and matched. The new syntax available also breaks with the Rails’ish Routes form, and lets you easily include regexp requirements for parts of the URL. Mako Automatic Safe HTML Escaping Simplified rendering setup that doesn’t use Buffet Simplified middleware setup with easier customizability Simplified PylonsApp for customizing dispatch and URL resolving and lots of bug fixes! There’s a more detailed page covering 0.9.7 changes available as well that can also assist in the rather minimal change needed for a 0.9.6 project to get going with 0.9.7rc1. Other things in Pylons-land With TurboGears2 extending Pylons for its foundation, many various parts of TG2 have become usable within Pylons, not to mention existing packages that have been getting better and better. ToscaWidgets has gotten drastically simpler, no longer requiring the rather confusing RuleDispatch package with its generic methods. This makes the tw.forms package install with a fraction of the packages it used to require, and since it comes with Mako templates won’t incur any speed bumps it used to have from its use of Genshi. The new Pylons tutorials for it also make it a breeze to quickly create large forms with advanced widgets. Some might have noticed that Reddit released their source code, which happens to be in Pylons. Their code is a good example of some of the customizing possible with a Pylons based project, as they added some custom dispatching to make controllers work in a more similar fashion to web.py controllers that they ported their app from. In a way, its similar to how TG2 has been able to support TG1 users for the most part by customizing Pylons to dispatch in a TG1 style manner. Profiling an application got a lot easier with repoze.profile, and I’m sure more cool bits of WSGI middleware will be coming out of the repoze project in the future, not including some of the past handy bits like repoze.who which is used in TG2 for its new identity system. I ported a little app that Robert Brewer wrote to track memory leaks. Being terribly uncreative on names for my new WSGI middleware version, I called it Dozer. It’s a handy little piece of WSGI middleware to throw in when you think you might have a memory leak to try and sort it out. Pylons is moving along quite nicely, and the amount of WSGI middleware and tools that work with it continue to expand which makes it hard to list all the cool new projects I’ve seen lately that work wonderfully with Pylons. Mako and SQLAlchemy continue to evolve with Mako having pretty much zero backwards incompatible changes in the past 6+ months, while SQLAlchemy slowly deprecates things as they prepare the 0.5 release. These packages have massive amounts of features and are rapidly becoming very stable easily making Pylons + Mako + SQLAlchemy a tough combination to beat. [Less]