Integrating structlog with logot

[etianen]

Hello! 👋 I've just released logot, a log testing library. One of it's things is the ability to integrate with 3rd-party logging frameworks, and it launched with support for loguru.

I've since had a couple of people ask whether it could support structlog, with someone offering to author a PR. I was hoping you could answer a couple of questions, as I've not used structlog myself. 🙏

What is a good version range to support? I was thinking v23-24, since that covers a year of releases. However, your security policy seems to indicate some very generous backwards compatibility guarantees, so I was wondering about going with an uncapped supported version?

How can I avoid stepping on the toes of your built-in testing tools? You've included some nice built-in testing tools, very comparable to caplog and assertLogs. The assertions provided by logot are higher level, with some nifty things like:

• Support for log message matching using %-style placeholders.
• Support for log pattern matching using log pattern operators.
• Support for testing threaded and async code.

Hopefully that would be seen as an extension to what you're offering, for cases where more complex log assertions are helpful. 🙇

Are you happy for me to link to this from your third party extensions wiki page? Kinda the same question as above. Given the overlap with your own testing tools, are you happy for me to link out to it?

Any integration tips? It looks like a pretty straightforward integration using a custom log processor. One thing I'm struggling to find in your docs is a way of removing a log processor once added. In other words a way of adding a log capturer at the start of a test run, and removing it at the end, restoring the previous log configuration.

Thank you! ❤️

[etianen]

I already answered my last question by looking at the source code of capture_logs 🙇

[hynek]

What is a good version range to support? I was thinking v23-24, since that covers a year of releases. However, your security policy seems to indicate some very generous backwards compatibility guarantees, so I was wondering about going with an uncapped supported version?

I don't think it's useful to make abstract claims like this, as you've noted yourself. I would try to check if the original testing helpers from 20.2.0 work like the current release for you intents and purposes and call it a day.

How can I avoid stepping on the toes of your built-in testing tools? You've included some nice built-in testing tools, very comparable to caplog and assertLogs. The assertions provided by logot are higher level, with some nifty things like:

• Support for log message matching using %-style placeholders.
• Support for log pattern matching using log pattern operators.
• Support for testing threaded and async code.

Hopefully that would be seen as an extension to what you're offering, for cases where more complex log assertions are helpful. 🙇

What exactly do you mean by my toes here? 😅 If you mean ego-wise, I can assure you I'm extremely happy about any project that improves a) structlog and b) testing in general. ;)

I only haven't added more high-level tools to structlog proper because quite frankly I don't want to maintain them. But internally, I have similar helpers like you're building.

Are you happy for me to link to this from your third party extensions wiki page? Kinda the same question as above. Given the overlap with your own testing tools, are you happy for me to link out to it?

Please, by any means!

Any integration tips? It looks like a pretty straightforward integration using a custom log processor. One thing I'm struggling to find in your docs is a way of removing a log processor once added. In other words a way of adding a log capturer at the start of a test run, and removing it at the end, restoring the previous log configuration.

I already answered my last question by looking at the source code of capture_logs 🙇

AFAICT this was the only technical question so you should be unblocked on technicalities? 😅

[etianen]

Thanks! Regarding your toes 🦶, I wanted to make sure you didn't have any plans of your own to expand the structlog testing tools, or held some strong opinion that what you'd already provided was already good enough for anyone! I've seen a few cases of this sort of thing being shot down before!

Thanks for the version range suggestion, and for your time and encouragement! I'll close this now with a 🖖.