uberlogging 0.5.0

为什么

每个项目都是从日志配置的负担开始的。 我们需要用于交互调试的颜色，本地纯文本 重定向到文件时为dev，在生产环境中运行时为json 有中央日志收集系统。最后，我喜欢 structlog， 但是大多数库都不使用它，所以我需要配置 两个库都是兼容的。

这个库正是这样做的-按照描述配置日志记录 上面。它同时用于structlog和标准库日志记录。

固执己见？

是的，因为它只是配置由 其他伟大的人会按照我个人喜欢的方式行事。

例如，我更喜欢not来呈现structlog的key/val 在json输出中作为独立属性的参数，因为我发现 把它们作为短信的一部分读起来就方便多了， 即使在诸如graylog这样的集中式日志ui中，也要处理它们 因为单独的字段需要我启用一百万个字段列， 因为每个日志消息都有自己的上下文；而且我不使用日志， 但更广泛分析的指标。

用法

importuberlogginguberlogging.configure()

就这些。你准备好了。只需导入structlog或标准 库的logging，创建日志并开始编写应用程序。

为了方便起见，structlog的get_logging被提升到uberlogging:

logger=uberlogging.get_logger("main")logger.info("Rocky road",to="Dublin")

定义UBERLOGGING_FORCE_TEXT=1环境变量 强制在非tty流中输出文本。在以下情况下对本地环境有用 使用输出重定向运行应用程序。

环境覆盖

有时人们想要自己的方式，而这并没有改变实际的代码。 为了解决uberlogging提供的控制某些配置的能力 尽管环境变量：

UBERLOGGING_FORCE_TEXT

定义为非空值以强制文本（而不是json）输出。自动检测着色

UBERLOGGING_FORCE_TEXT_COLOR

与上述相同，但颜色始终为启用

UBERLOGGING_FORCE_TEXT_NO_COLOR

与上述相同，但颜色始终为禁用

UBERLOGGING_MESSAGE_FORMAT

重写日志消息格式的字符串。 例如"{asctime} {levelname} {message}。注意只有{ styles 支持。

在stdlib字段之上，uberlogging还提供扩展的context字段 到StructLog提供的字符串化上下文（键/值对）或空字符串，如果 使用stdlib记录器。

测试在哪里？

没有测试，只有截止日期：） 不过，说真的，现在有demo.sh脚本已经足够好了，因为 这个图书馆不会有太大的发展。

仅在Python3.6+上测试！流配置仅适用于Python3.7+。