On Sat, May 29, 2010 at 12:46 AM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
>
> On May 28, 4:48 pm, Russell Keith-Magee <freakboy3...@gmail.com>
> wrote:
>> Following some discussion at the DjangoCon.eu sprints, here's what
>> we've got on the table regarding adding logging support to Django.
>>
>> The core of Vinay's work is essentially ready to go -- the logging
>> configuration code is an implementation of what has been accepted as a
>> PEP, so there's no reason for us to use anything else.
>>
>> As for landing this in trunk - the consensus is that this should be
>> done in two parts:
>>
>> The first commit will be the the actual core logging infrastructure -
>> the logging config parsing module, and the hooks to get a logging
>> configuration parsed and installed.
>>
>> The second commit will be the addition of actual logging. The
>> intention here is to be initially conservative; two immediate targets
>> would be to replace calls to mail_admins() with logging calls, and
>> replacing debug messages in management commands with their logging
>> equivalent.
>
> Makes sense.
>
>> At this point, it largely becomes a political problem -- we don't want
>> Django's core to get bogged down in trivial logging calls, so we need
>> to develop our policy on when we add a logging statement to trunk, and
>> at what trace level, and so on. Of course, none of this prevents end
>> users from putting whatever logging they want into their own code. It
>> also doesn't prevent the core logging code and initial logging calls
>> being added to trunk; we can develop the logging policy over time once
>> the core is in place.
>>
>> On a technical level, the only issue that needs resolving is the issue
>> of how to trigger configuration of logging in the first place. The
>> current patch implements this using signals (a bootstrap plus pre/post
>> model load signals). The consensus at the sprints is that we should
>
> They're not of course signals in the dispatcher sense - just ordinary
> functions which get called back directly from the framework code.
>
>> take this opportunity to kill an old request -- 'startup' handling.
>>
>> Under this proposal, startup would look like this:
>>
>>  * Once settings have been successfully imported, logging is
>> configured based on settings.LOGGING. This guarantees that logging
>> will always be configured, rather than relying on users successfully
>> invoking logging in their own settings file or similar. This will
>> essentially replace the BOOTSTRAP_CALLBACK in Vinay's current patch.
>>  * We then look for a 'startup.py' in each app included in
>> INSTALLED_APPS, and import that module. This is the replacement for
>> (PRE|POST)_MODEL_CALLBACKS in Vinay's current patch
>
> Replacing the BOOTSTRAP_CALLBACK with auto-configuring logging via the
> LOGGING setting will of course work, but not be as flexible as things
> are at present. You won't be able to do anything else at that time -
> you just get logging configured for you, under the hood. Now that
> isn't a problem since the dictConfig API should handle all of the
> common and less-common scenarios, but if a user had a valid reason for
> doing logging configuration their own (different) way, or doing their
> own early-phase setup code, they'd be out of luck.

My concern here is YAGNI. Can you suggest a specific use case where
this will actually be required?

>> This provides a convenient entry point for configuration items such as
>> signals. The only runtime guarantee for startup.py is that the
>>
>> settings have been imported. This means that you should be able to
>> import models, register for signals, or anything else you may want to
>> do on startup.
>
> This implies that all the startup.py importing would be done in a
> separate loop after all the model loading is done - i.e. the
> equivalent of my POST_MODEL_CALLBACKS hook.  If so, how could you hook
> into class_prepared, as per my example? Can you confirm that's the
> intention?

No - the startup files would be imported immediately after
configuration has completed, but before any models have been loaded.
This is probably closest to PRE_MODEL_CALLBACKS in your setup. This
means you could connect to the class_prepared signal in startup.py.

There is a potential race condition here. A model import that occurs
in startup.py will cause the model loading infrastructure for that
model to be invoked. This means it would be possible to load a model
before you get a chance to install the class_prepared signal handler.
However, the same race condition exists in your own proposal. If you
did a model import in a pre-model-callback, that would cause those
models to be registered, so a pre-model callback can't actually
guarantee that the models *haven't* been loaded.

This is just one of the unfortunate eccentricities of Django's model
loading and registration process. The only solution I can offer here
is to say that the order in which startup.py's will be invoked will be
predictable, so if you need to guaranteed that a class-prepared
handler will be added, you can add an app to INSTALLED_APPS whose only
purpose is to register a handler for class_prepared signals, or jiggle
the order of INSTALLED_APPS to avoid this sort of side effect.

The issue of adding other signals is orthogonal to the logging
request, AFAICT. You could certainly make an argument for a
"apps_loaded" signal that is emitted after all the INSTALLED_APPS have
been loaded. However, I don't see that this is a specific requirement
for logging, and as long as we provide an entry point early in the
startup process, I don't see that this is something that requires a
callback system independent of Django's existing signals framework.
Again, if you can provide a specific use case to prove otherwise, I'm
willing to be convinced.

Yours
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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