> Maybe I'm oversimplifying this - and I'm sure if you'll tell me if I > am ;-) - but how about the following: add a setting called e.g. > SETUP_CALLBACKS (or whatever name you prefer) which will be an > iterable (say, tuple) of callables which are called from > Settings.__init__ in the same way that Simon's code on ticket #12012 > works. In fact you could have two sets of callables, one before > INSTALLED_APPS loading and one after, if you wanted to.
There really is no such thing as "INSTALLED_APPS loading". I think you mean "model loading"... if so, it's not quite so simple. Maybe there's a way to make this approach work, but it's at least not as easy as "let's just add these two settings". > Obviously the callables would be restricted in what they could do, but > it need be no worse than the restrictions on e.g. what you can import > in settings.py. The big offender here is that __import__ (and thus "import ..." and "from ... import ...") has consequences. Models are initialized the first time the Python interpreter sees them. I'll illustrate why this is a problem through an example: Lets say you have myapp/bootstrap.py and bootstrap.py does an import (from myapp.views import some_signal_i_care_about) and myapp.views imports myapp.models. Right there... with two seemingly innocuous imports, we've broken the contract that the environment is pristine. Now, if we register a listener for class_prepared, it will never* get called for anything in myapp.models, or anything imported there. (* >From memory... this is true unless there's a deferred processing of a model relationship, in which case it's even harder to predict the outcome) So, given the current state of affairs it goes beyond just "what they could do" to "what could be imported". Even a stray import in an __init__.py could create a series of problems. > Obviously this approach could be tweaked - e.g. instead of a tuple of > callables, you could have a tuple of (callable, args, kwargs) - but > that's detail. Is the basic idea workable? If we're building a bootstrapping system, it's likely possible to introduce some additional logic into the metaclass approach that models use, and work around this case.... but it's non-trivial. I'd love to take a stab at this again, but am not sure when I'm going to have time... so I'd be quite happy for someone else to beat me to it. 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 -~----------~----~----~----~------~----~------~--~---