Configure a LoggerAdapter about backoff

[achiang]

I guess the brute force way to do it would be to monkey patch backoff's logger, but hoping for something cleaner. 🙈

[bgreen-litl]

I missed this issue when it came in. This seems like a reasonable request but any explicit support is something I'd have to think about more.

Rather than monkeypatch, you can supply your own logging function to backoff via event handlers https://github.com/litl/backoff#event-handlers

You could imitate the default logger implementations here and have them use your adapter instead of the default backoff logger.

There's a few requests out there for more explicit customizable logging for backoff but I've been reluctant to do it thus far. For your use case, it might be as simple as providing a backoff.set_logger() method, but I'd have to think about it more.

[bgreen-litl]

I'm poking at the idea of adding a set_logger() API function.

my_adapter = MyAdapter(logging.getLogger('backoff'))
backoff.set_logger(my_adapter)

Do you think that covers your use case?

[achiang]

Thanks for considering this feature!

The API looks reasonable, but it's not totally clear to me when an app should be setting backoff's logger in this manner. For example, imagine the following app layout:

tmp$ tree
.
├── app.py
├── blueprints
│   └── api.py
└── lib
    ├── bar.py
    └── foo.py

app.py contains all the Flask init code. It is where we would also configure logging using logging.config.dictConfig.

Each module has a module-level get_logger call, right at the beginning:

from app import get_logger
logger = get_logger(__name__)
...

So in this example, if both api.py and lib/foo.py import backoff and want to use it, when is it appropriate to call backoff.set_logger()? It seems a bit weird for app.py to import it and configure it at log configuration time, especially if app.py never makes an explicit call using backoff.

Anyway, perhaps I am just very confused on this topic, so in the interest of not blocking progress, I would say that providing that API makes sense, and I think app developers can make it all work. :)

Thanks again!

[bgreen-litl]

@achiang It's been a long time, but please check out #64 if you're still interested in this.