A brief history of TurboGears

An email from Jimmie Houchin has convinced me to take a few minutes out and explain where TurboGears came from and why it has emerged on the scene now. One note about how I’m writing this: there are many good tools for Python that solve a variety of needs. Since I’m not out to disparage other people’s work here, I’m not going to mention tools that I had been using or tools that I decided not to use.

In December, I decided to build Zesty News in Python after considering several alternatives (Rails, Seaside, Java-based tools). Python had nothing as slick as Rails for doing webapp development, but it had a whole bunch of great tools for other parts of my application.

I started working in earnest on Zesty News in January. I had to go through the same collection of reading about and deciding on pieces of the puzzle that everyone does when they start creating a webapp. (Side note: Zesty News is a “desktop webapp”… users install it on their machine and it runs a webserver to provide the bulk of the UI.)

I chose the tools that seemed, after a little digging, to be the best combination. The only one of those tools that is part of TurboGears is SQLObject. Development proceeded fairly smoothly until May, and then a funny thing happened on the way to release. I changed gears and decided to strongly emphasize plugins within Zesty News.

That notion changed the direction of things considerably. I wanted to provide a great API for building plugins, as this would benefit me (the full version of Zesty News will be built as plugins on top of the free version) and everyone who wants to customize the program. Toward the end of May, CherryPy became my web framework of choice.

In June, I dealt with a bunch of database nastiness that I never would’ve had to deal with if Zesty News was purely web-based and not a desktop app. Once I left that behind and got back to business, I realized that I would have to get together some decent documentation on the framework I was using to show people how to build plugins. I figured that if I’m doing that work anyway, I might as well package everything up conveniently and make the whole thing one nice, tidy open source package. That was around the end of June or early July.

Around that time, I started pestering Phillip Eby on the distutils-sig list about Python Eggs. I knew that something would have to be done to make TurboGears install easily, and Phillip had a rapidly maturing answer to that problem.

Then, Bob Ippolito started teasing us with promises of a cleaner JavaScript framework. I pestered him to give me a preview and had soon replaced my other JavaScript framework with MochiKit.

Bob was extolling the virtues of attribute-based templating languages when I took another look at Kid. My first look at Kid had been much earlier in the year, and I wasn’t particularly impressed. When I looked again in July, I knew I had found the ultimate: easy and Pythonic, yet fully valid XML and viewable in the browser. It didn’t take me long to rip out my old templates and replace them with shiny new Kid ones.

After the release of the first Zesty News alpha, I turned my attention to preparing TurboGears for release. I went through some effort getting API docs together using a hacked epydoc that includes colorized source files. I cleaned up the code that creates the Blazing Things website and turned it into docgen.py that appears in TurboGears.

And, of course, I wrote, and setup servers and got domains, and figured out how to do a screencast and all that good stuff. Which is how we got to where we are today…

I’ve actively used different tools for all of the parts of TurboGears and read extensively about many more. I’m happy to have found a great set of tools that work well together, and it’s gratifying to know that I’ve helped other people to use them as well.

(Not such a brief history, huh? Unfortunately, I didn’t have time to make it shorter (paraphrasing Blaise Pascal).)

16 thoughts on “A brief history of TurboGears”

  1. > Since I’m not out to disparage other people’s work here, I’m not going to
    > mention tools that I had been using or tools that I decided not to use.

    But you *are* doing us a disservice by not mentioning them, and mostly by not mentioning the reasons that made you prefer something else to them.

    Of course, that would triple your story’s size, but maybe it would be worth it. 🙂

  2. “Je n’ai fait cette lettre – ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte”

    — Blaise Pascal

    The quote is sometimes attributed to Mark Twain, but it’s the first time I’ve seen it attributed to Ben Franklin ;-).

  3. That’s what I get for writing a long post late at night. I googled it and went with the first thing that I saw that matched. A googling this morning turned up a link that talked about Pascal and Twain.

    “Ask not what your weblog can do for you, but what you can do for your weblog”… paraphrasing Julius Caesar (just kidding 🙂

  4. As for the “not naming names” when it came to the other projects, not only would it make the story much longer, but it would likely be counter productive.

    Let me draw a comparison: how many times has the Emacs vs. vi argument come up? Once it’s established that you can edit text files with either one, you quickly devolve into matters of taste and opinion. Such arguments rage on endlessly, and I don’t have time for it.

    It’s much the same way with Python web frameworks. I chose one to begin with and changed to another within a couple of weeks. Then, in May I changed to CherryPy. Those were not hard transitions, because there was a lot in common between those three frameworks. (Switching to Zope certainly would have been a big change!)

    When you get down to it, all three frameworks that I actively developed with could put things on the web and get stuff from web requests. My reasons for switching to CherryPy had more to do with the little things (request parameters mapping to method parameters, for example) than anything else.

    There was one additional consideration, though: I didn’t want Zesty plugin developers to have to use callback-style programming. The reason I didn’t use CherryPy from the getgo was that I started off using an asynchronous framework.

    The same thing can be said about OR mappers, generally speaking. They all move data to and from the database. You just have to decide which style of API you like.

    I’ve said why I chose Kid. I’ve looked at a number of template libraries and Kid is the only one that provides a syntax that is as designer and programmer friendly.

    As for MochiKit, there’s certainly no other JavaScript library that is going to make a Python programmer feel so at home. It’s also got a very clean design with *docs* and *tests*!

    And, finally, as for any other all-encompassing toolkit: that was largely a matter of timing. The timeframes when I was doing my work were just not compatible with theirs.

  5. I think this is great man. I can’t wait to have some time to mess with this. I’m not really a Python guy, but about a year back I tried to pick it up by throwing together a quick website with Python since I’m mostly a web programmer. Big mistake for a Python newb! It’s almost impossible to figure out all the moving parts you need to make it happen. I think TurboGears could be a huge hit in the Python newb area, hopefully the name gets out in those areas as well as among the established python types.

  6. Thanks – it’s nice to hear about your process.

    I’m curious why you considered, but didn’t choose Seaside. I’m more a Python person than anything else, but Seaside’s got me learning, working in, and loving Smalltalk.

  7. Hey, turbogears looks really great, i watched the video and i’m gonna give try on it in a little while.

    “I’ve said why I chose Kid. I’ve looked at a number of template libraries and Kid is the only one that provides a syntax that is as designer and programmer friendly.”

    I know you wanna avoid comparisons, but did you tried ZPT before choosing Kid?

  8. Hi,

    Cool idea, and VERY easy to install. Thank you. I am wondering how you plan on handling changes in the various released components of TurboGears. For example, the Kid home page warns of imminent changes as they approach 1.0.

  9. > I know you wanna avoid comparisons, but did you tried ZPT before
    > choosing Kid?

    That’s a question I was going to ask as well…

  10. Pingback: Ajaxian
  11. Seaside is interesting, but I wasn’t confident that I could get the kind of other tools I needed for my application (embeddable database, making an app that has native aspects for Mac and Windows, etc.) Python has a wealth of libraries covering just about any need.

    I certainly did look at ZPT and had played with SimpleTAL. Ian Bicking recently summarized the differences between some of the template langauges out there:
    http://groups.google.com/group/turbogears/msg/4065ec5d5a0ee7b0

    The short of it is that ZPT uses TALES (a domain specific language) for its templates, whereas Kid is all Python. I think the learning curve is smaller with Kid and that the advantages of the DSL can be reduced by providing the right functions.

    As for “imminent changes” in Kid, I should really pester Ryan to get that text off of there… Ryan doesn’t have anything planned that would cause breakage of any kind.

    Your question about “handling changes in the various released components” is a great one, though… I’m happy to say that the answer is Python Eggs. Phillip Eby’s setuptools is *great* and solves the problem neatly. Eggs have versions attached to them and TurboGears can be as specific or general as we want it to be with respect to required versions. So, if we’re worried about changes to Kid (which I’m not), we would say that TurboGears requires “Kid >= 0.6.4,

  12. Amen to CherryFlow – I’d love to see that almost as much as I’d love to see turbogears and subway become one unified project.

    The only downside to cheryflow it is the dependency on stackless/statesaver. Which imho should be in core python anyway. The argument was always that jython can’t go there … but who in their gourd would run a web app megaframework over jython anyway?

Comments are closed.