One of the more interesting things I have started to use with some frequency is Sphinx. Sphinx is a documentation system whichallows you to create webpages (among other things) with .rst files. It also grabs directly from your modules and inserts your docstrings (including your doctests.) It is great to have code which is not only documented, but also tested using nose. Look for a screencast from me in the near future on this one.

Two of the recent screencasts I have written show how to use virtualenv, PasteScript, and Nose. I go through a ground-up example showing how to create a virtualenv, a project package, and finally how to test that package and provide robustness with code coverage. The final screencast is about how to install TG2, which has become much easier in the advent of TG2’s first alpha release.

TG2 is actually nearing it’s second alpha release. I think This is the best release yet. I spent some time moving DBSprockets to pep-8 compliance, and the two things TG2 depends on (tg.ext.silverplate and tgcrud) are now both using the newest release of DBSprockets. I also released basketweaver which allows you to create a simple local pypi made of static HTML files. Special thanks to Chris McDonough, who wrote the makeindex.py script. All I did was to fixed it up a little, and package using PasteScript, and provide a console_script for easy usage.

Along with Sphinx, I have been trying to wrap my head around Rum, which is a new project to generate forms from database schema, much like DBSprockets. Although the internals of the system are somewhat mystifying, the API is squeaky clean, and in my mind what DBSprockets was eventually planned to be. The great news is that Alberto has done such a good job laying the groundwork for Rum I should be able to jump right in and apply lessons learned from DBSprockets. At this point it is safe to say that I will continue to maintain DBSprockets for bug fixes, but that the internals of it are going to be converted over to using Rum, before being deprecated altogether. DBSprockets had a great run, but it is time to move on and move forward with a superior design which promises to integrate so many WSGI technologies.

My own ideas revolve around DBSprockets and TwTools, which is not surprising since I am the owner of said projects.  The largest project and the one which I have the most desire to see put into action is that of a TurboGears CMS.  There had been some work done last year by the guys at Pagoda which produced a brilliant screencast, but the project seems stalled out and it would be nice to see it revived.  Furthermore, the solution I proposed is intended to be much more modular, so you could pick apart portions of the CMS and put them in your existing applications.  I think this would be the most flexible solution, and also one which would employ much that DBSprockets, TwTools, and Toscawidgets have to offer.  If you are a student who is interested in working on this project, please don’t hesitate to drop me a line.  You can also track me down at Pycon for the remainder of the week, and at the TurboGears sprint next week.  If you are a student who is eager to get started feel free to participate in our sprint, remotely or in person.   

One of the great things I see coming from this mini-project is that we now have a very nice set of concrete ideas about how to make TurboGears better.  Whether or not students participate in the development we still get a huge benefit from the creation of ideas, and it gives the development team and possibly new developers a target to make TurboGears the best it can be.  My hope is that these ideas will not only bring a students to our project, but also bring some developers out of the woodwork who may have started similar projects and would like to contribute.  The bottom line is, if you aren’t a contributor, and want to be, here is a great place to start.

First off I wanted to commend Mark for his insightful post. Mark certainly has considerable perspective on both frameworks, and has a great ability to divulge the best of both. He is often pointing me in directions so that I might make DBSprockets better. One day I even received a link to a Ruby on Rails application, ActiveRecord. He certainly can think outside of the box when it comes to solving the world’s Python Framework dilemmas, and is not afraid to express himself openly about his opinions.

“TG2, like Django will define a set of tools that can be used in building re-usable web site components. TG2 users should be able to powerful, reusable components, with SQLAlchemy, Genshi, ToscaWidgets, and the whole TG2 toolchain. ”

–Mark Ramm

I am so glad that Mark pushed TG2 in this direction. I am glad that he pushed DBSprockets in this direction. This week I
worked on getting DBSprockets to work within a Grok application. With not too much effort I was able to get Genshi, SQLAlchemy, and Toscawidgets working within a Grok environment. DBSprockets followed suit. I was amazed at how little work it was to get Toscawidgets working in Grok despite the complexity with which it interfaces the web framework. Granted, I did have to get Grok working through WSGI, and I have Repoze to thank for that. But in the end, all I had to do was easy_install the correct packages, and modify 4 lines in the .ini file, and poof, Toscawidgets in Zope. Who’d a thought a year ago (before the Pylons/TG “merger”) something like this was possible?

So what is my point? When I started out, I asked Mark for commit writes to TG so that I could build DBSprockets into it. The response was, “Well, no go off and do the google code thing and get back to us.” What a great move that was, because now I am able to support many more frameworks and have a much broader user base. And Django… you’re next.