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.