February 14th, 2008 by Mark Ramm
The SQLAlchemy migrate project has reawakened after a long slumber. And I couldn’t be happier. Evolutionary database development, or “migrations” as the Rails folks have re-labeled the process, is an important piece of the agile web development puzzle.
It’s possible to do without it but I can’t think of a single project I’ve worked on in the last couple of years that didn’t need something. I’ve helped to hack things together for various groups, and I’ve never been particularly satisfied with our one-off solutions. Particularly when everything I’ve worked on has had needed a robust, standardized system for mananging and versioning database schemas.
Today, thanks to Christian Simms and Jan Dittberner, SQLAlchemy Migrate now works with SQLAlchemy 0.4. Which means that I can now use in in almost every project I have. I expect that this will bring a new wave of users, and I know that it opens the door for a whole new set of features.
This is also a core feature that I think TurboGears 2 needs to have to really be complete web development toolkit, and now we’ve got it. I don’t want to sound like a broken drum here, but I’m very happy that this isn’t part of the TurboGears package. It’s better because it’s not part of the framework. Anybody who uses SQLAlchemy in GUI’s or in command line tools, or whatever can (and probably should) use these Migrate, and the likely wouldn’t want to install a web-framework just to manage their database schemas.
Question for the masses:
On another note, there’s one django project that is the only thing I’m currently working on that doesn’t use SQLAlchemy, and I must confess to being bewildered by the array of Django schema migration projects out there. So any of you Djangonaughts with advice, recommendations, tips on how to do schema evolution on that project would be very welcomed.
February 14th, 2008 by Mark Ramm
One of the things that slowed down the TG2 release recently has been the move to WebOb based Request/Response objects. There was some extra work required to make this happen right away, but I think it was worth it. WebOb provides an new and interesting approach to request/response objects that I hope will catch on around the Python web community. And it was likely that a switch would be inevitable, so we bit the bullet now in order to avoid future API changes.
Why WebOb?
A WSGI server (see www.wsgi.org) itself doesn’t do anything to provide a full featured web request/response object, but providing a simple CGI style “environment dictionary” and a callable for setting response headers. This is almost certainly the “right” way to do things for WSGI itself, because it provides a usable base, and avoids getting into framework specific issues, but there’s certianly room to provide a nicer API for end users than that.
Which is why modern python web frameworks, from Zope, to Django, Pylons, and TurboGears 1/CherryPy all provide users with a more “user friendly” request/response objects. Unfortunately they all implement different request/response objects, and their implementation is part of the “framework” itself so it isn’t easily reusable outside of the framework, and it certainly isn’t usable across frameworks. As I mentioned earlier, WebOb is an attempt by Ian Bicking to change that. The best thing about WebOb is that it is very much a friend of WSGI, not a competitor. It maintains the WSGI environment as the canonical source of data, and just wraps it in a nicer API.
WebOb makes fiddling with headers, cookies, and all that in your app easier. But it also makes writing WSGI middleware much easier. Several pieces of middleware used by TG2 have already been rewritten to use WebOb internally, and the authors report that WebOb has make thier life much easier. And it’s certiainly made their code easier to read and understand.
WebOb WSGI and re-usable components:
Appropriately, given yesterday’s discussion of re-usable components, the WebOb documentation has an interesting example of a commenting middleware component, that shows off how you can make “pure WSGI” components that are entirely framework neutral.
WebOb and the future of Python Web Development:
And it looks a bit like it’s happening, SkunkWeb, Pylons, and TurboGears 2 are adopting WebOb, and there’s been at least some talk about doing something similar in Django, which I think would help make it easier to write libraries that “just work” in multiple frameworks. Of course, we may never settle on one ORM, or one templating language, , but there’s a whole set of libraries that pretty much just need to manipulate the request and response objects and don’t need to interact with the rest of the framework. So, if several of the major frameworks move to WebOb (and WSGI of course) that would make the dream of cross-framework libraries much more of a reality.
I keep saying it, because I think it’s important, Python’s web framework diversity is only a hindrance if we 1) don’t work together, and 2) don’t learn from each other. And given the current crop of framework developers, I don’t see any chance of us not working together and learning from each other.