Open vikramsubramanian opened 5 months ago
Based on the ticket description, here are the recommendations for integrating logot
with loguru
:
Log Capture:
LoguruCapture
backend for logot
to unify capture between stdlib logging and loguru
logging.LoguruCapture
for loguru
.capturing
are propagated to the LoguruCapture
constructor.# Example of context manager usage with LoguruCapture backend
from logot.contrib.loguru import LoguruCapture
with Logot().capturing(LoguruCapture) as logot:
# Your code here
Log Message Matching:
.format()
-style placeholders for loguru
integration, as loguru
uses this style by default.logot
that can handle .format()
-style placeholders.loguru
.# Example of log message matching with .format()-style placeholders
from logot.contrib.loguru import logged
logot.wait_for(logged.info("Hello {}"))
# Example of matching structured data
logot.wait_for(
logged.bind(foo="bar").info("Hello {}")
)
General Advice:
LoguruCapture
backend combined with .format()
-style message matching to provide first-class support for loguru
.stdlib
interface.loguru
community and ecosystem to ensure that the integration is appealing and does not duplicate existing solutions.The provided code snippets from the loguru
codebase are not directly relevant to the implementation of the logot
integration but can be used as a reference for understanding how loguru
handles logging. The setup.py
and __init__.py
files indicate the package metadata and version, which might be useful for specifying dependencies and compatibility in logot
. The _logger.py
file contains the Logger
class and its methods, which will be important when creating the LoguruCapture
backend to ensure it interacts correctly with loguru
's logging mechanisms.
I've recently released a 0.1.0 preview of a log testing library called [logot]( It provides a nice fixture for testing [complex log patterns]( which I've found very useful when testing multithreaded and async codebases.
I'd like to provide a
loguru
integration. 🤗Since I'm not hugely familiar withloguru
, I was hoping you'd have some advice on what a good integration would look like.There are a couple of sticking points that I'd like to nail before committing to a v1.0.0 API.
hashtag Log capture
Currently, stdlib logging capture is enabled with a [context manager method](
Since the
loguru
integration would be an optionalextra
, a freestanding context manager could be provided like this:It's a bit awkward having a freestanding context manager for 3rd party integrations, so an alternative would be a capturing backend approach:
Any arguments given to
capturing
would be propagated to theLoguruCapture
constructor. This would then unify capture between stdlib logging andloguru
logging. The default capture backend would be the stdlib capture, and an ` would ensure good typing. 💪The alternative is a whole
Logot
subclass just forloguru
, which seems heavyweight and unpleasant. 🤮hashtaghashtag Log message matching
Rather than awkward regexes,
logot
lets you [match log messages]( with%
placeholders. The hope here is that it's much cleaner and more intuitive to match using the syntax used for log message placeholders. (Similar to howprintf
andscanf
pair nicely).But
loguru
uses lovely.format()
-style placeholders!Maybe it's fine to just use
%
placeholders inloguru
tests? 🤷But it might be nice to support
.format()
-style placeholders like this:Support for matching structured data would also be possible:
hashtaghashtag Advice appreciated! 🙏
Thanks for reading this far!
I'm inclined to go with a
LoguruCapture
backend combined with.format()
-style message matching. That would give first-class support forloguru
without compromising or complicating thestdlib
interface.However, I'm not really familiar with the
loguru
community and ecosystem! Maybe this is unappealing? Maybe it's already been done! 😬Hope you have a nice weekend! ❤️ )