Open vikramsubramanian opened 7 months ago
Based on the ticket description, here are the recommendations for integrating logot
with loguru
:
Log Capture:
LoguruCapture
backend as a capturing mechanism for loguru
. This aligns with the existing design pattern for logot
and provides a unified approach for capturing logs from both stdlib
logging and loguru
.capturing
are propagated to the LoguruCapture
constructor to maintain flexibility and configurability.Log Message Matching:
.format()
-style placeholders in logot
to match loguru
's logging style. This will provide a more intuitive experience for users familiar with loguru
.loguru
's bind
functionality.Integration Design:
Logot
subclass for loguru
as it would be unnecessarily heavyweight.logot
to understand loguru
's logging patterns and data structures through the LoguruCapture
backend and message matching enhancements.Here is a high-level overview of the pseudo code for the proposed integration:
# logot/contrib/loguru_integration.py
from logot import Logot
from loguru import logger
class LoguruCapture:
def __init__(self, *args, **kwargs):
# Initialize with any arguments passed to Logot().capturing()
pass
def start_capture(self):
# Logic to start capturing logs from loguru
pass
def stop_capture(self):
# Logic to stop capturing logs from loguru
pass
def get_captured_logs(self):
# Logic to retrieve captured logs
pass
# Usage of LoguruCapture with Logot
with Logot().capturing(LoguruCapture) as logot:
logger.info("Test loguru integration")
# Captured logs can be retrieved and tested
# logot/contrib/loguru_integration.py (continued)
from logot import logged
# Extend the `logged` function to support `.format()`-style placeholders
def logged_with_format_style(level, message):
# Convert `.format()`-style placeholders to `%`-style placeholders
# or implement logic to directly match `.format()`-style placeholders
pass
# Usage of `.format()`-style placeholders
logot.wait_for(logged_with_format_style(logger.info, "Hello {}"))
# logot/contrib/loguru_integration.py (continued)
# Extend the `logged` function to support structured data matching
def logged_with_structured_data(level, message, **kwargs):
# Implement logic to match structured data passed to `logger.bind()`
pass
# Usage of structured data matching
logot.wait_for(
logged_with_structured_data(logger.info, "Hello {}", foo="bar")
)
This integration approach should provide a seamless experience for users who want to test logging in their applications that use loguru
, while keeping the logot
API consistent and type-safe.
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! ❤️ )