TurboGears 2: a reinvention and back to its roots

Mark Ramm has just posted a glimpse of The Future of TurboGears. I wanted to post a little of my perspective and a historical view.

This past weekend, Jonathan LaCour, Mark Ramm, Rick Copeland, Noah Gift, and Mike Schinkel sprinted on TurboGears 2 (along with a bit of coding-from-starbucks-while-on-vacationby Alberto). TurboGears 2 is at once a reinvention of TurboGears and a return to TG’s roots. My original TurboGears 0.5 release was just a few hundred lines of Python code that built upon thousands of lines of other libraries. As people flocked to TG and added new, high-level features, it swelled to about 20,000 lines (and brought in even more third-party code).

TG is a project that is built upon a foundation of reuse and building up. In retrospect, much of the code that was home grown in the TurboGears project should have been released as independent projects that integrate with TurboGears. This would have allowed better growth of those pieces.

Alberto and I have talked about this a bit along the way. And there were lots of interesting discussions at PyCon this year about how Pylons and TurboGears have similar philosophies, though we disagree about some of the details (Hi, Ben!). The details that we disagree on are important and user-facing, but are actually not a big deal when it comes to the framework code. We can share an awful lot of code.

Just days ago, Mark Ramm and Jonathan LaCour (both at Optio) had the realization that TurboGears should just go ahead and make the switch. When Mark told me about the idea, I thought it made perfect sense. TurboGears 2 will go back to what TG originally was: a powerful package of best-of-breed tools. TG2 is once again a tiny core, getting features from a variety of other packages.

A lot of the groundwork for this had been set in place prior to the new TG2 sprint. Alberto’s ToscaWidgets reimplemented the TurboGears widgets API. Babel provides an internationalization package with features similar to, but more extensive than, TurboGears’. Various authentication and authorization systems have been worked on, though I don’t believe one has been chosen yet for TurboGears 2.

I’m really excited about TurboGears 2 and the significant activity that is going on in the project right now. After some months of deciding what TurboGears 2 would look like, we now have an answer that will get us to release in short order and fine form. *And* we have a good path set up for the TurboGears project to build new high- level tools as independent (and hopefully usable by others!) projects.

Of course, there are details to work out, docs to write, some tools to build, etc. But I, for one, am quite happy and thankful to the folks who have pitched in to put TG2 on this path. Thanks to all who have worked on Pylons, Paste, Genshi, SQLAlchemy (and Mako when speed is critical), Beaker (and MyghtyUtils, without which there would be no Beaker), all of the template engine plugins, setuptools, the still- quite-cool RuleDispatch, Babel, CherryPy, and, of course, TurboGears.

6 thoughts on “TurboGears 2: a reinvention and back to its roots”

  1. I love that TG2 will be going the direction of smaller core framework, in favor of using more functionality from other packages. I have been building a small open source web publishing framework using TurboGears, but I find that I am not using a large portion of the TG core. One of the goals of my project is to keep the core small in favor of simplicity and maintainability. I am in favor of small frameworks that use best-of-breed tools over big frameworks that try and reinvent everything. Keep up the great work.

  2. I have used TG for about 6 months but I haven’t used Pylons at all.

    I originally choose TG as a way to provide integration of all the elements necessary to build an app: server(cherry), logic(cherry/TG), templates(kid) and backend(sqlobject). It basically all worked with few problems. As an aside, I never really “got” widgets seemed mostly to be a template issue to be solved with kid, and a lot of work for not too much in return.

    My real question though is: What is the main focus of TG? Is it integration of best of breed web projects? Pylons seems to do this too, as you wrote above in very similar ways. If so, with this announcement you seem to be giving the nod to pylons as a better way of doing it. This doesn’t make sense as you clearly are continuing with TGv2.

    You allude to how TGv2 will differ from Pylons:

    “The details that we disagree on are important and user-facing, but are actually not a big deal when it comes to the framework code. We can share an awful lot of code.”

    Can you explain how the two projects differ in their approach?

  3. TG and Pylons both share the notion of reusing code from other projects as much as possible. The difference between the two can be seen on their web sites: Pylons angles for being all about choices (though it comes with some defaults), whereas TurboGears takes the defaults more seriously. TG2 still offers CherryPy-style dispatch as the default way to lay out controllers, which Pylons certainly doesn’t do. TG2 uses Genshi as the default template engine.

    Also, TG2 provides a “full stack” installation process that includes things like ToscaWidgets. With Pylons, those are optional.

    So, there’s only a small amount of code that’s different. The difference between TG2 and Pylons is much more in packaging and presentation. And that was the goal! No one wants to duplicate effort on random pieces of infrastructure.

  4. Thanks for taking the time to reply to my question Tazzzzz. I look forward to seeing how TG2 works out when the details are a bit clearer!

Comments are closed.