TurboGears 1.1 and Beyond

I just posted this to the TurboGears announce list. We’ve been working hard to come up with the right plan for how to move TurboGears forward as quickly as possible, while giving people the features they need, and I think we’ve got a good plan.

Recently there have been a number of requests for more clarity about the future of TurboGears, and since I’ve been involved heavily with a couple of experimental projects designed to help us explore our options, I’d like to help clarify things as best I can.

A bit over a week ago several of us decided to get together in Atlanta this past weekend and hack on an experimental Pylons/TurboGears integration project. We wanted to discover if we could re-implement the TurboGears API on top of paste+pylons in a way that would make TurboGears better.

The goal was not just to re-implement things, but to see if that re-implementation actually improved the readability, flexibility, and ease-of-mantinance of the TurboGears project. In other words, we wanted to make TurboGears: easier for new developers to work on, easier for us to maintain, and more flexible so we can take advantages new python web developments in the future.

On all counts, I think we can now say that this experiment has been a huge success. And after lots of good discussion with Alberto, Kevin, and Ben Bangert from the Pylons project, the way forward is now much clearer. The results of the sprint will become the basis for TurboGears 2.0.

To make life easy for people who want to install TurboGears 2.0 alongside the current version we will be creating a new package called tg for TurboGears 2.0. And Alberto is planing to promote it out of the pygears branch into trunk today.

The new tg package will implement a very large percentage of the current TurboGears API, and thus is intended to provide an very easy upgrade path for current TurboGears users. In particular current controller code should be very simple to port, and Kid, Genshi, SQLAlchemy, and SQLObject code will be supported, so most of your template and model code will require almost no changes, or will be be usable as is.

There’s still work being don on TurboGears 2, and it’s hard to predict a release schedule in open source projects. But if you pressed me I would say that I expect to see a beta in the next couple of months. It could be earlier, it could be later… If you’re the adventurous type and don’t want to wait until then can check it out of subversion today, but expect a lot of rapid changed.

At the same time the turbogears development team will continue to maintain and support TurboGears 1.x for our current users. We want to accommodate users who create new TG 1.0 projects for a long time, but we also want to make it easy for those who want the latest and greatest stuff to get started with TurboGears 2.0 as soon as possible.

There will be a TurboGears 1.1 beta release in the next few weeks, which will fully support the current API, and will switch the default templating engine from Kid to Genshi, and the default ORM from SQLObject to SQLAlchemy. This release will not include an upgrade to CherryPy 3, because that has required backwards incompatible changes, and has taken much more work than expected. If someone wants to take up the standard, there may be a TurboGears 1.2 wiith CherryPy 3 support, but as far as I know nobody had volenterred to do this.

And of course, SQLObject and Kid will remain supported in 1.1, to give us full backwards compatability with current applications. Catwalk and Model Designer will remain SQLObject only applications in 1.1.

And that brings us back to TurboGears 2.0. In addition to the current TurboGears API, the new tg package will support all kinds of new features that will make our user’s life easier. Many of these features are the direct result of our integration with Pylons, because we’ll be getting access to a lot of great stuff they’ve already done. And we’ll be sharing almost all of our infrastructure code with another group of great developers.

The end result is that TurboGears users that have sites that need to scale up, will have have access to world class caching options (including memcached support), as well as a number of other performance enhancing features and options. For the majority of us who are more interested in rapid development, and deployment flexibility, than raw performance, TurboGears 2 will include all kinds of new features. TurboGears 2 will also implement a more flexible Object Dispatch system, as well as direct Routes integration, so it will be even easier to get exactly the URL’s you want.

There’s a lot more going on too like 1.1 TurboGears 2 will make Genshi and SQLAlchemy the defaults because they provide a better experience for the majority of web developers. We won’t be forcing our opinions on anybody, and other ORM’s and templating engines will be supported, but we’ll be focusing all our documentation effort on those defaults. We want to make very sure that our documentation tells a clear and compelling story about how this stack of components makes web development easier.

At the same time, we’ll be working to support people who want to develop and maintian sub-projects for automatic CRUD (like Catwalk or the Django interface) outside the TurboGears 2 core. Our hope is that these tools will be broadly usable by anybody who is working withing the context of a framework that implements the Web Server Gateware Interface standard. Ultimately I think Pylons, TurboGears, Paste, Zope, and all kinds of other python web developers toolkits will be working together on creating great tools for rapid development.

Thanks to Pylons, Paste, SQLAlchemy, Genshi, Babel, and a whole host of other contributions from around the web TurboGears development is getting easier and more fun. I for one, am really looking forward to all the good things that are in the pipeline!

I’m looking forward to some spirited discussion of the TurboGears 2.0 plan, and the plan for TurboGears 1.1 on the TurboGears trunk mailng list.


5 Responses to “TurboGears 1.1 and Beyond”

  1. 1Dieter

    So, why should I use TurboGears at all after its developers throw away half of its components to replace them with others which will be more or less compatible? My suggestion to you TG core developers is: Stop developing TG2 now, at least for a little moment, and show your users how they will migrate their TG1 projects to TG2. If you don’t make that point clear how the upgrade path is and that that path is very easy to go then you will really loose a lot of your users to other frameworks.

  2. Dieter,

    Thanks for the feedback. I understand what you are saying — and I have to say I agree with the sentement, but not the strategy.

    We need to do a bit more work on TurboGears 2 in order to get it to the point where it is easy to use and easy to upgrade too, so stopping development now would be a mistake.

    But I fully intend to create a document “Upgrading the 20 min Wiki” which takes the 20 min wiki and moves it to TurboGears 2. I think you’ll find that it’s really easy — which is a requirement for me personally because I have some large TurboGears projects which I’ll need to migrate to TG2.

    So, I personally am very committed to making it easy to upgrade, because if it isn’t I’ll be hurting myself. ;)

  1. [...] hoje apareceram dois posts importantes, pois tratam do futuro do framework. O primeiro que li foi o post do Mark Ramm, resumindo os acontecimentos e decisões tomadas num sprint [...]

  2. [...] TurboGears’ announcement that version 2.0 will be built on Pylons. If this is news to you see Mark Ramm, and Jonathan LaCour’s posts and the mailing list thread. It is great to see such positive [...]

  3. Web-Frameworks: TurboGears 2.0 wird auf Pylons aufsetzen…

    Wer vor der Frage steht, ob er TurboGears oder Pylons nutzen will, bekommt bald eine interessante Antwort: Beides gleichzeitig….

Comments are currently closed.