Werkzeug Identity Crisis?
After the Werkzeug 0.1 release I got some feedback by Ian Bicking. Summarized it was about why Werkzeug pretty much does what webob does. Afterwards I thought about the issue and talked with some current Werkzeug users. And to sum it up: Werkzeug stays a standalone library without webob dependency and will stay with the current request/response object implementation.
While I agree that there are things webob does what Werkzeug (currently?) does not provide such as byteranges I still think it’s on the right path. We have now a solid feature set in Werkzeug itself such as form data parsing, file uploads, conditional requests, simple redirects, useful exceptions, a good routing system, a simple bridge to wsgiref for a development server, a small helper library for management scripts and much more and additionally an optional contrib package with dozens of small helpers such as client side sessions, utilities for application sessions, the iterio library, a stream limiter for Django applications etc.
Even more important than having everything you need to get started with WSGI in one library the implementation is easy to understand, fast and written in a way that you will never hit a border. If you find a piece of code in Werkzeug that only solves 90% of your problem but provides absolute no way without side effects to get the full 100% solution that’s a bug and should be fixed.
The minimal configuration you need to get a full featured web app running in a production environment with Werkzeug is currently something like Werkzeug + Genshi + SQLAlchemy + flup. Makes a total of four dependencies. It’s not like I think dependencies are problems but what I noticed so far is the more libraries a user has to install the higher the number of problems and the lower the number of happy users. This is one thing Django does right: install django and you’re done.
If you don’t like that philosophy there is pylons with a whole string of dependencies ;-)
I’m a fan of dependencies, but then again it’s apt-get, and yum simplifies all that for us.
Werkzeug looks interesting, I will need to try it soon.
Comment by Braydon Fuller — Sunday, December 16th, 2007 @ 4:46 amI think that Werkzeug is quite light on the dependencies. Those chosen, which just happens to be the developers choice, aren’t as bad as 15 where you don’t really have any idea how they fit together.
Comment by Scott Benjamin — Monday, December 17th, 2007 @ 3:47 amI think free of dependencies web-framework is best than not free. But I must let us change one component by another. May be not all components but many… This is the medial way (so the best way like in yoga or buddism, isn’t it? :)
Comment by Pavel — Wednesday, May 28th, 2008 @ 8:39 am