This recent patch:
> @@ -93,7 +93,8 @@
> try:
> fp = open(filename, 'w')
> except IOError:
> - logging.error('Unable to write to file %s' % filename)
> + if not is_gae:
> + logging.warning('Unable to write to file %s' % filename)
> return
> portalocker.lock(fp, portalocker.LOCK_EX)
> fp.write('# coding: utf8\n{\n')
reminded me of another patch I've been thinking about, and gave me an idea for
a grander design.
The problem is that GAE logs *everything* (ignoring the current loglevel); they
want you to filter in the log viewer rather than the logger. They may be right,
but as in the above example it leads to a lot of noise and discourages the use
of even debug-level logging.
The patch I've been thinking about is for rewrite, which routinely logs some
top-level information (logging.debug) about what it's doing to assist in
debugging router files. A long time ago I had added a logging-control parameter
to routes.py, so that you could turn routing logs on and off that way. When we
added support for logging.conf (see logging.example.conf), I gave routing its
own logger and took out the parameter: control it the way you control
everything else, through logging.conf.
Except for GAE...
The patch I was thinking originally (and still am) is to reintroduce the
logging parameter to routes.py and make its logging conditional on that
(details tbd; maybe it wants to mention a level instead of being simply a
boolean).
But now I'm thinking that a more universal solution would be to enhance
web2py's logging capability to make this kind of solution available to any app
or module.
Right now, a module like gluon.rewrite logs this way:
logger = logging.getLogger('web2py.rewrite')
...
logger.debug('some debug message')
(where web2py.rewrite is parameterized in logging.conf)
Suppose we replace the call to logging.getLogger with a function that returns
logger in a wrapper. The wrapper would somehow know (tbd) what level we're
logging at, and because it wraps methods like .debug simply doesn't call
logger.debug if unless it really wants to log.
This is all rather fuzzy, since I'm not sure how we'd want to control it; the
logic might want to look at whether we're running on GAE. But it seems wasteful
to sprinkle GAE-specific workarounds throughout web2py, especially in places
(like rewrite) where sometimes we really *do* want to see the logs.
