[Yum-devel] RFC: logging/output

[Florian Festi]

We had quite similar problems in pyrpm.

James Antill wrote:
>  So first off I'll try and list the problems with the current approach
> to logging/output:
> 
> 1. Function names are way to long, Eg.
> self.verbose_logger.log(logginglevels.INFO_2, msg)
Passing a loggin level sucks - infoX and debugX (dbgX) is definetely the way 
to go.

> 2. We have 20 distinct levels/interfaces right now ... not including
> "print".
Having a lot different level is not a problem per se but you need a policy 
how to assign them. Without a policy the levels are just useless. We always 
grouped 3 debug levels together to be used at a certain level of 
functions/methods. Toplevel methods debug1-3 (1 on toplevel, 2 for loop, 3 
for nested loops) and debug4-6 for worker methods and debug7-9 for helper 
methods.

> 3. We don't cover the common cases well, for instance I think these
> would be considered the common things you'd want:
> 
> i. quiet
> ii. normal
> iii. verbose
> iv. debug (more in levels, sections or whatever).
> 
> ...now IMO #iii is the biggest problem due to a bunch of debugging data
> mixed in so isn't that usable/used.

Next thing that we came accross is that info and debug levels don't mix 
well. It turned out info and debug needed to be separate levels. Having a 
lot of info does not mean showing any debug messages and vice versa.

> 4. Almost everything goes off of
> YumBase.logger/YumBase.verbose_logger ... except some parts of the code
> which don't have access to a YumBase object.

Global debug settings turned out to be not that practical for a bigger 
project. To get around this we use a logger that can be turned on and off 
(switched to a given level) for modules, submodules, classes or methods - 
without telling every logging call where it is located. This is achieved by 
using black magic that involves - along other things - snake skin.

It also allows to add the location of the logging call to the message format 
string (e.g. module.class.method:lineno, filename:lineno, ...)

> 5. Also kind of related is that we don't have much in the way of good
> output data utilities, for instance section headers.
Ehm, I don't get this...

Code can be found here:
http://www.jur-linux.org/git/?p=cvs-pyrpm.git;a=blob;f=pyrpm/logger.py;h=d171c420f63e84bcda1d68020b1cdb1868e29e6a;hb=master

Florian