WSGI and cooperation
Wow, lots of interesting discussion based on my last post about a Django developer discovering how rich the WSGI middleware ecosystem has become. And I actually think that the discussion there is very enlightening.
But I think those who criticize WSGI often miss the real point. I think WSGI is interesting not because of how amazing it’s API is, but because it’s provided a clear way for the many python web development communities to work together, and to swap and trade technologies.
Many things that used to be part of the Zope application framework, have been turned into WSGI middleware by the repoze folks (repoze.profile, repoze.tm, repoze.retry, etc) while things that used to be TurboGears framework specific have moved out to become libraries with middleware components (ToscaWidgets, repoze.what, etc).
Pylons was built from the ground up using WSGI Components, and has contributed a bunch of great components.
And then there’s Ian Bicking who has contributed a huge array of tools for working with WSGI stacks paste contains all kinds of stuff like the paste cascade app, paste script, and most importantly webob. WebOb is very lightweight, just an OO proxy over the environ, and a few helper methods, but it makes writing WSGI middleware and WSGI applications much easier.
The point of all this is that the wider python web world is seeing a huge increase in cross-polination of ideas, of working together on projects, and sharing code across major frameworks from TurboGears to Zope, to Pylons. And at the core of all this is the WSGI specification. WSGI may not be pefect, but it’s still great, because it provides a defined way for web framework developers to work together. And, that coupled with the fact that we’re all pretty friendly people, and we all like each other and want to work together on things, has created a renasance of sorts in python web tools world.
It’s now easy enough to pull tools together and make your own webframework that I know a couple people folks who’ve created 2-3 specialized frameworks for various projects in the last year. This is great because they can take only what they need, and also because they have contributed back inovative bits and pieces, and have also helped improve some of existing pieces at the same time.
Sure, it’s a little bit messy and chaotic when compared to more centrally controlled framework development, but it’s also a whole heck of a lot more interesting, flexible, and fun. And there’s a whole lot of interesting new ideas getting tried out.
TG2′s goal is to provide an opinionated, coherent, facade across this complexity. We want to be coherent, without being monolythic, to be full-stack, while allowing the user control over the stack.
Django developers sometimes criticize the wsgi world for not providing a complete and integrated toolset. And that’s exactly the problem that TG2 is determined to solve. If we’re doing our jobs right TG2 will provide what we think are best of breed components, put together in a coherent, and easy-to-use way. We want users to be able to depend on the stack and to be able to build reusable applications on top of it. And that requires being opinionated. But we also want to make it possible for users with different needs to make different choices when and where the need arises.
One TG2 developer said it this way “We want TG2 to have strong opinions, loosely held,” and I think that’s about right. We want to provide a clear path that works and works well, with a solid foundation, but we also want to have the humility to know that the opinions we bake into our framework are not always right for every web-app. And we want to trust our development community to know when to stay one the easy path, and when to try out new ways of doing things, or use WSGI components that work better for their apps.