I see the utility of being able to have additional ways to setup the
logging, though as it is I think the biggest issue people have with
the logging stuff is that the dictconfig is already fairly
intimidating looking. If someone really wants to disable the default
setup of logging, it should be as simple as flipping a setting, then
calling their own loggers by hand in settings or __init__.
I think primarily the first goal should be with the logging stuff to
do like Russ detailed, and replicate the current functionality of the
exception handling and admin emails.
I'd also be curious as to if you guys think it would be a good idea to
integrate the messages framework with python logging. It seems like
it follows a similar paradigm, though there might be some snaffu's
with trying to get access to the request object in a handler/logger.
And though we've been showing mostly complex fancy examples to demo
the power of the dictconfig stuff ... you can actually make really
simple concise configurations as well.
ie:
config = {
'handlers':{'stream':{'level':'DEBUG',
'class':'logging.StreamHandler',},
},
'loggers':{
'django':{'handlers':['stream']},
}
}
My current branch of django-experimental has a working implementation
of the exception handling and query logging (lifted from simon's
initial proposal).
There is also a proof of concept project I started called django-
lumberjack that will work in 1.2 to demo how the handlers, backends,
and formatters can be integrated with current profiling, debugging
tools we use. I took the middlewares from dcramer's devserver
project, and the handlers from zain's jogging. I haven't tested the
email handlers, though the pygmented terminal output of exceptions and
queries should be working out of the box.
-k
On May 28, 12:46 pm, 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.
>
> > 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?
>
> Thanks for your feedback!
>
> Regards,
>
> Vinay Sajip
--
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.
