On Mon, Sep 27, 2010 at 11:16 PM, Luke Plant <[email protected]> wrote: > Hi Russell, > > On Sat, 2010-09-25 at 14:16 +0800, Russell Keith-Magee wrote: > >> At this point, I'm calling for feedback, particularly on the following: >> >> * logging config as the last stage of settings loading. Is this the >> right place? Can anyone think of a better place? > > In the context of running a Django app, this means it will definitely > get called before the first request is dispatched, due to the need to > find the URLconf. From the context of command line apps, it is less > predictable in general, but I guess the command line app has to be > responsible for ensuring that logging gets set up first. > > Anyway, this seems good to me, and I can't think of a better place. For > the probably rare case of putting logging calls in your settings.py > (like Hanne Moa does), there is nothing to stop you setting up logging > yourself inside settings.py, which Hanne must presumably do already. > The only problem is that logging could be set up twice. For this case, > I guess we could support some convention like 'LOGGING_CONFIG = None' to > stop Django configuring logging altogether and add a note in the docs. > This might also be useful for the command line app situation.
Sounds reasonable to me. I'll add handling for the None case. >> * The startup.py convention (and implementation). Is this necessary? >> Does it address (or not address) any other prominent "on startup" use >> cases? There's also a crossover here with Arthur's GSoC work; is the >> startup code sufficiently important that we need it anyway, or can we >> defer until the app refactor lands? > > I'm not sure what use cases this specifically targets. It seems that it > depends on 'AppCache._populate' being called. From what I can tell, > that isn't guaranteed to be called until some database query is made, or > it is called by an app like the admin. Without the admin I can create > an app that never populates AppCache but can serve responses. > > I don't see anything that depends on this startup proposal though, so > I'd propose dropping that part until the other options have been > discussed. The use case for logging is completely customized, programatic logging configuration. If you look at the settings.py that Vinay uploaded to #12012, you can see an example of what he had in mind. From my tinkering with the patch, this isn't a particularly compelling use case; a custom logging config function should be able to handle this much better. The larger use case is to introduce a consistent place to do per-app configuration, like registering signal handlers. However, the app-cache refactor work from Arthur has a much more consistent story on this. I think your suggested approach may be right -- drop the startup proposal from logging (which doesn't strictly need it), and let Arthur's work pick it up. 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
