After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 345734 - Should Dogtail use the standard PEP282 logging module rather than define its own
Should Dogtail use the standard PEP282 logging module rather than define its own
Status: RESOLVED WONTFIX
Product: dogtail
Classification: Deprecated
Component: Framework
CVS HEAD
Other All
: Normal normal
: ---
Assigned To: Dogtail Maintainers
Dogtail Maintainers
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2006-06-23 10:48 UTC by Dave Malcolm
Modified: 2011-02-07 06:05 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dave Malcolm 2006-06-23 10:48:26 UTC
Please describe the problem:
Dogtail has its own logging.py module.

A "logging" module was added as a result of PEP 282 to Python 2.3:
http://www.python.org/dev/peps/pep-0282/

API docs are here:
http://www.python.org/doc/current/lib/module-logging

Should we simply recommend the use of this module?  This has a 
"logging.foo()" API, rather than a "log.foo()" API.   Ideally we'd like timestamps as well.

Steps to reproduce:



Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Edward Rousseau 2006-06-23 16:13:15 UTC
Does the module fit our needs? With most test tools you want your debug log tied to you test run and definitely your results log is going to be tied to the run. It is definitely worth exploration but the logging use case for a test tool is very different than pretty much any other type of application. At first glace this looks a bit like trying to fit a square peg into a round hole.
Comment 2 Peter Parente 2006-10-09 19:28:36 UTC
The configurability of the standard logging module is desirable for testing Linux Screen Reader. What we need is a way to interleave output from the screen reader and dogtail into a single log file, like so:

[dogtail INFO] starting test id #gedit-001
[lsr INFO] File <group>
[lsr INFO] menu item <role>
[lsr INFO] New <item>
[lsr INFO] Ctrl-N <hotkey>
[dogtail INFO] ending test

We do this today by:

1) defining an XML-RPC handler for the logging system
2) running an XML-RPC server that simply dumps messages to a file
3) configuring the logging system in both LSR and dogtail using a logging config file
4) manually adding logging statements to dogtail scripts

It would be better if dogtail supported the standard logging module for all of its logging such that the test harness could configure it externally. For instance, test LSR, we could use an external xmlrpc.conf file to tell the test system to use our XML-RPC handler, what channels to log, what levels to log at, etc. With all log calls in dogtail supporting this configuration, we won't have to manually add references to our logger in dogtail scripts.

This doesn't mean that you have to sacrifice simplicity for configurability. The default configuration for the logging module could be whatever you currently have. Plus, you can simply bind the log object info method (debug, warn, whatever) to the name of the function you currently have for logging (log(msg) ?).

Here's the code we use in LSR, for your reference.

xmlrpc config file
http://cvs.gnome.org/viewcvs/lsr/test/xmlrpc-log.conf?rev=1.2&view=markup

xmlrpc server
http://cvs.gnome.org/viewcvs/lsr/test/logserver.py?rev=1.1&view=markup

xmlrpc client code
http://cvs.gnome.org/viewcvs/lsr/src/LSRLog.py?rev=1.2&view=markup
Comment 3 Fabio Durán Verdugo 2011-02-07 06:05:24 UTC
dogtail development has been stalled and it has been unmaintained for a few
years now.
Maintainers don't have future development plan so i am closing bugs as WONTFIX.
Please feel free to reopen the bugs in future if anyone takes the responsibility for active development.