On Sat, Oct 10, 2009 at 10:52 PM, Simon Willison <si...@simonwillison.net> wrote: > > On Twitter Malcolm pointed me here: http://code.djangoproject.com/ticket/5685
That's my ticket, and I had mostly forgotten about it. As you've found out, there is no way to hook into the bootstrap process. For signals, we just stuff them somewhere (typically __init__.py or models.py) where we expect them to be imported. I've always felt that this is a bit of a kludge, but there's been no better way to handle it. Right now the primary solution is to patch Django itself, and there are at least a few place where that could be done. Your approaches (modifying the settings or models modules) rely on incidental behavior -- these modules happen to be loaded in almost every case, so whatever we throw in there will also get run. The path I took was a more traditional approach to bootstrapping -- attaching the functionality to the code entry points: the various request handlers and the management command module. I'm still not happy with the implementation in the patch on that ticket, but I think it's in the right direction. Because of Django's initialization procedure, addressing the bootstrapping process is actually a bit complex: * Some things need to be run before any models are loaded. Specifically... anything that wants to listen to the class_prepared signal. This is quite hard because an accidental import of a model creates all sorts of mess. * Some things just need to be run before the Django environment is used (to run a management command or handle a request)... registering signal listeners, for example. * Logging may need to come even earlier. If you truly want to log everything, you'll want to run that code first. The reason I opened #5685 was primarily because there is no way to solve this problem without either: 1. Patching trunk or 2. Writing a bunch of custom wrappers around the Django code to do the setup... and these wrappers are tedious, easy to screw up and don't play well with each other. That means: I'm strongly in favor of any hook to allow code to be run before the Django environment is setup, and I'm not tied to any particular path of solving the problem. Best, - Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
