However, I think something is missing from the discussion: You don’t have to go all or nothing with any of the components you choose to use.

We use SQLAlchemy, Django’s ORM, and an in house CouchDB library at WWU Housing. We can still use django pluggable applications, we have the power of SQLAlchemy for mapping objects to the atrocious tables in Banner, and we have the flexibility of a schema free document database with CouchDB. Why should we limit ourselves to one?

Its ridiculous; use the tool for the job.

Nice write up, although I cringed reading my first sentence you quoted, remembering what my writing looks like when I lack the foresight to edit.

Coupling/integration can be difficult to discuss, as it hinges pretty heavily on definition. Identically to your example about turbogears 2 plugins relying on SQLAlchemy, the vast majority of Django applications rely on the Django ORM. It is trivial to use Django without the Django ORM, if and only if you’re willing to sacrifice using those Django applications.

I’ve done projects with Django and CouchDB, where the ORM is entirely unused. For these projects I wasn’t able to use some apps (unless I wanted to run both CouchDB and postgres), but the Django core didn’t raise any complaints.

More concisely, I’d suggest that the core is loosely coupled, but the application ecosystem is tightly coupled. But now I’m starting to draw a possibly artificial distinction between the core and the ecosystem.