I enquired with @hynek regarding how to implement this within a library. His abridged response:
There are basically two problems to be solved:
- How to configure? I think the user should configure structlog themselves and should be required to tell your lib explicitly that it wants to use structlog.
- How to log? Since structlog with its k/v support is a superset of logging and you want k/v logging this is not trivial. I think the best way would be to write a very thin shim that allows for
log.info("event", x=y, a=b) and if structlog is not used, it’s will either format the k/v or transform it into logging-specific context information by passing it into logging.info("event", extra={"x": y, "a": b})?
Point 2 is mostly just a suggestion/request for comments, since nobody has done that publicly so far…
As an aside, the currently logging system does need a drastic overhaul. It is a bit rickety and it's saving grace is simply that it hasn't needed any modification in a long time. (See #16)
Any new logging system should avoid string interpolation, thereby allowing us to re-enable the logging-fstring-interpolation / logging-format-interpolation pylint checks
I enquired with @hynek regarding how to implement this within a library. His abridged response:
There are basically two problems to be solved:
log.info("event", x=y, a=b)and if structlog is not used, it’s will either format the k/v or transform it into logging-specific context information by passing it intologging.info("event", extra={"x": y, "a": b})?Point 2 is mostly just a suggestion/request for comments, since nobody has done that publicly so far…
As an aside, the currently logging system does need a drastic overhaul. It is a bit rickety and it's saving grace is simply that it hasn't needed any modification in a long time. (See #16)
Any new logging system should avoid string interpolation, thereby allowing us to re-enable the
logging-fstring-interpolation/logging-format-interpolationpylint checks