Experimentation and Sprints in TurboGears

A bit less than two weeks ago Jonathan LaCour and I were driving down 400 into Atlanta for the Atlanta Python Users group meeting and we were taking about the pace of development in TurboGears recently.

And even though there is evidence that there’s been reasonable activity on the project recently. We both had general sort of feeling that the project was stuck and not moving forward the way we’d like. As a whole the project was focused on trying to provide maximum backwards compatibility as we created TurboGears 1.1, but that had turned out to be lots and lots of relatively uninteresting work, and given our limited resources was just not progressing that quickly in terms of new featurs or new releases.

As we talked about the core TurboGears we used day in and day out at work it became more and more obvious we could probably implement that same core API in top of Paste/Pylons relatively quickly, perhaps even over a single weekend sprint.

sprinting

So, while we were still on the way to PyATL, we came up with a set of two goals for our little experiment and ended up announcing it at the PyATL meeting that night. We wanted to

Things flew together very quckly, and one week later, I flew back down to ATL for a trip to Optio Software, and five of us met up at Jonathan’s house the following morning, for a day of fun filled hacking.

While Jonathan and I worked on hacking out the dispatch piece of RhubarbTart to include in Pylons, Rick Copeland quickly re-implemented cherypy style dispatch in a new, more flexible way. Soon we were able to convert a new pylons project to the TG style dispatch, setup a simple default route, and go.

Our next job was to get the @expose style decorator working in turbogears. Our plan was to push the work of actually creating the correct responses down into the base controller class, and just use @expose to register attributes on the function. That way the decorators could do just one thing — registering how to respond to particular requests. Our new @expose decorators look the same as the old ones, but are much, much simpler, and it will be much easier to extend them in the future.

Pylons buffet support helped out greatly, because we were able to get Genshi, and Kid working right out of the box. And the very first time we tested automatic JSONification via TurboJSON everything worked immediately — since it’s just an Buffet engine. We did have to do a bit of work to make sure that the special Pylons context object was filtered out.

With all that done, we decided it was time for dinner at the Mello Mushroom where they had much needed beer and pizza. Over some BBQ chicken pizza we discussed what still needed to be done. We’d pretty much acomplished our goals for the weekend already. But we had time so we decided we needed support for positional parameters, the input validation, and the @error_handler decorator and a few other things.

Back to Jon’s house we went. Where after much spirited discussion Mike Shnekel eventually convinced us that it might be a good idea to use extension names as part of the content negotiation process. So, a request to turbogears.html would go to the turbogears method, with a request for HTML results, and a request to turbogears.json would go to the turbogears method with a request for a JSONified result, and a request to turbogears.txt would ask for a plan text version.

We all agreed that was good enough for one day, and decided it was time for sleep.

We met again at Pannera Bread on Sunday, worked on database issues, got error handling working, talked to Alberto about possible validation implementation ideas. Implemented one way of doing things, while Alberto implemented another, and we finally resolved the issue in a better way than any of us had thought of before we came.

We also created a paster template for creating a new TurboGears project, in much the same way that you could with tg-admi quickstart. Noah Gift made a version of tg-admin that does exactly what you’d expect it to. The other tg-admin tools like tg-admin sql create are not yet ported, but Noah says he will continue to work on the.

Oops, as some folks were leaving for the night, I discovered the Pannera in Dunwoody closes at 7pm. And I was tired anyway, so I decided to call it quits for the night.

We definitely got more done than we thought we would.

Our littleexperiment was an unqualified success. We were able to get the core TurboGears API working very quickly, with very little code, and even to add a couple of new features as we went.

I think experimental code like this is one of the best reasons to get together and sprint. It’s a lot of fun, the energy is high, and you can really test out an idea quickly.

And I think the results of our experiment will be extra useful because we made intentional implementation choices to keep our new TurboGears layer compatible with regular Pylons, so you should be able to mix and match TG style controllers with Pylons style controllers and use Routes along side TG style Object dispatch. Very cool.

Thanks everybody who showed up.

Since the sprint, we’ve been talking about how this impacts our plans for the future of TurboGears. But, more about that soon, hopefully tommorow. But I’ve got a bit more hacking to do tonight. :)

5 Responses to “Experimentation and Sprints in TurboGears”


  1. Congrats to all involved! Sounds productive and fun. Looking forward to hearing more about your plans for TG.

  2. thanks for your work and for hold out
    cheers,
    heimo

  3. It really was a lot of fun, and I am very excited about the future of TurboGears!

  4. Congrats!

    It’s a pity I didn’t attend such a historic event; look forward to seeing TG 2/Pylons materialize.

  5. 5DamionKutaeff

    Hello everybody, my name is Damion, and I’m glad to join your conmunity,
    and wish to assit as far as possible.

Comments are currently closed.