[Yum-devel] RFC: logging/output

[James Antill]

On Mon, 2008-03-10 at 15:18 +0100, Florian Festi wrote:
> 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.

 *nods*

> > 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.

 Well, sure, but atm. we have 20 different levels and I've no idea what
the difference is between info and info1 ... nevermind "verbose" info.
 I'll try converting the rest of yum/*.py and then we can see if
"verbose" critical/error are used anywhere. I'm also suspicious of
"verbose" warn.

 So I'm pretty sure we could start by dropping the usage down to a
smaller number of levels ... and then maybe add some well defined levels
back, if we feel the need. But atm. I see "yum -q", "yum", "yum -v" and
"yum -d 5" as the only really used cases.

> > 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.

 Well I don't think we have that problem, maybe if we ever get to the
point where info goes to one place and debug to another.

> > 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, ...)

 Well my main goal was to be compatible with what we have, so we/I could
roll it out in pieces (I've already run with the current changes). Atm.
we have just levels, after converting everything to use the small
"global" functions it should be fairly easy to setup file based
"sections" (so you can turn off/on just the depsolver, for example).

> 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

 So I'm prepared to be convinced otherwise, but it didn't seem worth it
to have a container object for the logging functions ... apart from that
I don't see which parts of the above we could easily take into the yum
code.


 Anyway, I'll try and convert the rest of yum/*.py today and get another
patch for people to look at ... with some stats. on what we are using
where.

-- 
James Antill <james.antill at redhat.com>
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.baseurl.org/pipermail/yum-devel/attachments/20080310/072dcc84/attachment.pgp