Django’s Achilles’ Heel

It should clear from this blog that I’m a big fan of Django.  I use it for as much of my work as possible.  Recently a couple of other developers in my shop have entered the Django arena, which, as a general proposition, is a good thing — in that we’re using the framework more widely.  But as a result, one of Django’s few weaknesses has been made more painfully obvious, namely, the fragility of Django projects.

The problem is that one import error in any installed app’s models, any referenced URLconf, view module, or other module imported by one of those breaks the entire project immediately and horribly.  This makes the installation of new apps and updates of installed apps inherently risky to the entire site, which IMO is a *bad thing*.  Now, I haven’t delved into the guts of Django’s initialization process to see what, if anything, could be done about this, but on a conceptual level it seems that the project as a whole should have some way to recover from a bad app or module, unless it’s related to the core functionality of the project (like a middleware or context processor module).

Is that unreasonable?

Advertisements

  1. #1 by Mike Korobov on August 26, 2009 - 7:43 am

    Hiding errors is always a bad approach. It makes debugging hard.

    I think what you need is a better deployment strategy.

    For example, you can create 2 instances of your project on server. The one available to public may be set via symlink. Test new things on non-public instance. If all is working ok, point symlink to this instance.

    If you want these instances to use different sets of django apps and python modules, virtualenv will be helpful.

  2. #2 by David Chandek-Stark on August 26, 2009 - 2:40 pm

    @Mike – Thanks for the suggestion, although it doesn’t strike me as very manageable or scalable. I disagree that hiding errors is always bad, especially if you have a DEBUG setting, as in Django. In any case, I’m talking about *catching* these exceptions, not necessarily silencing them.

  3. #3 by lewis2007 on July 26, 2011 - 1:17 am

    For a scalable and manageable solution David, I am assuming you have a proper development approach here and are obviously using at least a staging and live server setup? Done. You should also be testing the entire project before deploying, which would catch these errors.

    You won’t hit these problems with proper setup. With Mike on this, why hide errors and let the app break when a user is browsing.

  4. #4 by David Chandek-Stark on July 26, 2011 - 9:51 am

    @lewis2007 – Point taken. This post is a couple years old, and my Django testing and deployment strategies have evolved.