Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Support structlog within libraries, redux

Open
  • Is something wrong?
#815 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
38/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
python
Domain
backend

Research direction

Start with the linked reader implementation in src/reader/_logging.py and the issue’s requirements for switching library loggers between standard logging and native structlog. Review structlog’s logger factories and existing tests to assess what public support is feasible; done means agreeing on an API and implementing and testing the required logger reset and stacklevel behavior. The discussion has not reached a decision, so check with maintainers before starting.

Written by the indexing model from the issue text.

Description

Hi @hynek,

This is a follow-up to https://github.com/hynek/structlog/issues/179 – I have a recipe for library support, but it could be made less brittle with support from structlog.

To summarize the requirements:

  1. the library MUST NOT configure logging nor structlog (that's for the user to do)
  2. the library MUST be able to use structlog internally
  3. if the user configures logging, they MUST get logging output from the library (there's a sensible event k=v ... default formatter; the library MAY offer a way to configure that, but it seems YAGNI)
  4. if the user opts in, they MUST get structlog output from the library
  5. it is acceptable for the user opt in to work only before the library is used, threads are started, structlog is configured, etc. (the library can document this accordingly)

The code is here; in short:

  • the library keeps a registry of its loggers
  • by default, it wraps a logging logger
  • during the opt-in, existing loggers are reset (details below)
  • after the opt-in, loggers are created with structlog.get_logger

Usage looks this:

# library.py

_registry = WrappedLoggerFactory(... wrap_logger() kwargs ...)
# library uses this exclusively to create its loggers
get_logger = _registry.get_logger  
# users call this to opt in
enable_native_structlog = _registry.enable_native_structlog

# user code

import library, structlog
library.enable_native_structlog()
structlog.configure(...)

library.do_stuff(...)

Minimal support from structlog would require:

  1. A (public) way to "reset" loggers created by wrap_logger and get_logger.

    My current code assumes both return the same type of object, which holds the entire state in its __dict__, so I can do:

    logger.__dict__.update(structlog.get_logger(name).__dict__)

    This is currently true (BoundLoggerLazyProxy), but it's obviously brittle.

    (More complicated alternatives that do not require structlog cooperation: wrap the returned object in another proxy; record the call site, and during opt in go in sys.modules and replace the loggers.)

  2. A (public) way to fix the stacklevel per logging logger.

    In WLF.get_logger, I'm temporarily doing logging.setLoggerClass(_FixedFindCallerLogger). This is still brittle, since stdlib loggers for my library could be created before the library calls WLF.get_logger (e.g. by logging.config.dictConfig).

    I guess an alternative would be for WLF.get_logger to patch the findCaller of the stdlib logger, instead of bothering with logging.setLoggerClass. Update: yup, seems to work fine.

    (This is optional, a library should be able to implement this without making assumptions about structlog internals.)

structlog could also provide something higher level like WrappedLoggerFactory; in this case, the stuff above doesn't need to be public API anymore, just possible.

What do you think? (If the overall direction is acceptable, I can draft a PR.)

Dominant language
Python
Stars
5k
Forks
302
Avg merge
17m
Merged PRs (30d)
4

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from hynek/structlog

All issues in hynek/structlog

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.