logical logging - at last!
Kevin Dangoor
everything is now piped through Python's logging module and is very
flexibly configurable via the config files. You can reroute access
logs with the "turbogears.access" logger.
If you look at a brand new quickstarted project, you'll see a fairly
large section of dev.cfg devoted to logging. I'm debating about moving
some of that out into turbogears.config (the handlers and formatter).
The advantage is smaller and less intimidating config files. The
disadvantage is that it's not as obvious to someone what to do if they
want to change things. Opinions?
My hunch is that people aren't generally going to change much from the defaults.
Kevin
--
Kevin Dangoor
TurboGears / Zesty News
email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com
Mark Ramm
> My hunch is that people aren't generally going to change much from the defaults.
That seems right to me. If you want to avoid the learning curve
turning into a learning wall, you could just add a comment in dev.cfg
and prod.cfg pointing the user to turbogears.config if they need to
tweak the log settings.
--Mark
Jorge Godoy
> I just committed a big change to how logging is configured so that
> everything is now piped through Python's logging module and is very
> flexibly configurable via the config files. You can reroute access
> logs with the "turbogears.access" logger.
VERY interesting. Specially to incentivate good practices.
It is also a sign the there will be problems integrating TG with Jython, at
least, because the logging "API" was introduce in Python 2.3. I dunnon how
easy it is to wrap that to the logging API from Java, from which Python
inherited some things (all of it?).
> If you look at a brand new quickstarted project, you'll see a fairly
> large section of dev.cfg devoted to logging. I'm debating about moving
> some of that out into turbogears.config (the handlers and formatter).
> The advantage is smaller and less intimidating config files. The
> disadvantage is that it's not as obvious to someone what to do if they
> want to change things. Opinions?
>
> My hunch is that people aren't generally going to change much from the
> defaults.
I'd put them on app.cfg or make a special log.cfg inside config depending on
how big it is. I prefer smaller files, so I'd probably make it two files.
Moving it there is needed because there are configurations that are common to
both development and production mode.
If we have good defaults -- on in development, off except for errors and
warnings in production -- I don't believe people will notice or care for it
if they don't want to.
--
Jorge Godoy <jgo...@gmail.com>
Kevin Dangoor
>
> Em Quinta 27 Abril 2006 13:54, Kevin Dangoor escreveu:
> > I just committed a big change to how logging is configured so that
> > everything is now piped through Python's logging module and is very
> > flexibly configurable via the config files. You can reroute access
> > logs with the "turbogears.access" logger.
>
> VERY interesting. Specially to incentivate good practices.
Yeah, with reasonable configuration, we can now put useful logging
messages throughout TurboGears code to help people troubleshoot
problems.
> It is also a sign the there will be problems integrating TG with Jython, at
> least, because the logging "API" was introduce in Python 2.3. I dunnon how
> easy it is to wrap that to the logging API from Java, from which Python
> inherited some things (all of it?).
TurboGears will not run on anything less than 2.3, and I'm far more
concerned with providing a good experience for people using CPython
than worrying about potential Jython users.
> I'd put them on app.cfg or make a special log.cfg inside config depending on
> how big it is. I prefer smaller files, so I'd probably make it two files.
That's a great idea. I'll have to fiddle with the code a little bit,
but I think I can do that. Though I agree that a separate log.cfg
would be nice, I'll probably drop them in app.cfg for now because that
requires fewer changes.
Kevin
Jorge Godoy
> That's a great idea. I'll have to fiddle with the code a little bit,
> but I think I can do that. Though I agree that a separate log.cfg
> would be nice, I'll probably drop them in app.cfg for now because that
> requires fewer changes.
If in the future you read log.cfg before reading app.cfg -- if possible -- I
believe we can change approaches in a backwards compatible way. :-)
It is better having logging in app.cfg than not having it so I don't mind
having a big file as well (hey! I already have httpd.conf and other Apache's
mess... ;-))
--
Jorge Godoy <jgo...@gmail.com>
Michele Cella
Great work Kevin, and +1 for log.cfg when possible. :-)
Ciao
Michele
Kevin Dangoor
> Great work Kevin, and +1 for log.cfg when possible. :-)
Already done :)
Kevin
Michele Cella
Oh that's great, are these tickets fixed now?
http://trac.turbogears.org/turbogears/ticket/609
http://trac.turbogears.org/turbogears/ticket/609
Ciao
Michele
PS
Don't forget the CHANGELOG diff I have sent to you. ;-)
Kevin Dangoor
> Oh that's great, are these tickets fixed now?
>
> http://trac.turbogears.org/turbogears/ticket/609
> http://trac.turbogears.org/turbogears/ticket/609
I think I'm seeing double. 609 and 609 are both fixed. :)
Kevin
Michele Cella
D'oh!! :D
http://trac.turbogears.org/turbogears/ticket/506
not sure about this one, this is probably internal TG conventions?
disclaimer: haven't read the whole ticket
Ciao
Michele
Kevin Dangoor
The configuration part of this is done, but we should still document
logging conventions for people working on TurboGears.
Kevin
Max Ischenko
> I just committed a big change to how logging is configured so that
> everything is now piped through Python's logging module and is very
> flexibly configurable via the config files. You can reroute access
> logs with the "turbogears.access" logger.
Great.
> If you look at a brand new quickstarted project, you'll see a fairly
> large section of dev.cfg devoted to logging. I'm debating about moving
> some of that out into turbogears.config (the handlers and formatter).
> The advantage is smaller and less intimidating config files. The
> disadvantage is that it's not as obvious to someone what to do if they
> want to change things. Opinions?
I'm not a fan of standard logging configuration syntax but good that at least it moved to separate log.cfg file.
Given that "most people won't change defaults" and default format is so elaborate and "low-level" I'd like to see a more high-level logging configuration. How about having a couple of "coarse" log-related settings in config file and use log.cfg if they are missing?
Kevin Dangoor
> I'm not a fan of standard logging configuration syntax but good that at least it moved to separate log.cfg file.
>
> Given that "most people won't change defaults" and default format is so elaborate and "low-level" I'd like to see a more high-level logging configuration. How about having a couple of "coarse" log-related settings in config file and use log.cfg if they are missing?
ConfigObj's nested sections make that configuration a little more
pleasant, but I agree that it is a somewhat elaborate format.
There's a tradeoff there. The way it is now, if someone needs
something beyond the default, it is a bit clearer looking at the files
to know how they would accomplish what they want. By providing them
with standard handlers and formatters, at least they're generally just
configuring loggers.
If we just had a couple of coarse logging settings in the default
files, then it would be a bigger hurdle for people when they need to
do something more. It's a tradeoff...
We *do* actually have those coarse logging settings: the existing
CherryPy log_to_screen and log_file settings. Those have been updated
to run through the new logging setup.
Kevin
Jorge Godoy
>
> There's a tradeoff there. The way it is now, if someone needs
> something beyond the default, it is a bit clearer looking at the files
> to know how they would accomplish what they want. By providing them
> with standard handlers and formatters, at least they're generally just
> configuring loggers.
There's also another problem. We have the configuration repeated in dev.cfg,
sample-prod.cfg and log.cfg... If someone needs something beyond the
default, what configuration file is the most authoritative? Is log.cfg
already working?
--
Jorge Godoy <jgo...@gmail.com>
Kevin Dangoor
Yes, and there shouldn't be any configuration repeated... the files
are doing different things. (Handlers/formatters are defined in
log.cfg, loggers are in the other ones.)
Kevin
Jorge Godoy
>
> Yes, and there shouldn't be any configuration repeated... the files
> are doing different things. (Handlers/formatters are defined in
> log.cfg, loggers are in the other ones.)
They are. I just got the impression they weren't because of their name and
the nesting level in the configuration. Sorry.
--
Jorge Godoy <jgo...@gmail.com>