> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to