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?
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.
Comment by Mike Korobov — August 26, 2009 @ 7:43 am
@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.
Comment by David Chandek-Stark — August 26, 2009 @ 2:40 pm