What
Provide a public API to set logger (and, for consistency, tracer) configuration programmatically at runtime, so users can enable/disable a logger or adjust its config without relying on the private _-prefixed API.
Background
PR #5380 wires Logger.enabled() to consult LoggerConfig.is_enabled. The configuration itself is already settable programmatically today, but only through private API:
_LoggerConfig(is_enabled=...)LoggerProvider._set_logger_configurator(logger_configurator=...) / the _logger_configurator constructor argument
This came up in review on #5380 (#5380 (comment)), where the question was raised that it should eventually be possible to set this via a public API.
Why this is a separate change
The tracer side is the template for this code and is also still private (_TracerConfig, TracerProvider._set_tracer_configurator). Promoting logger config to a public API in isolation would diverge the two signals. This should be a deliberate, consistent cross-signal decision (traces and logs, and any future signal), so it does not belong inside the enabled() PR.
Proposed scope
- Decide on the public surface for setting config on a provider (configurator callable vs. direct config object, naming).
- Apply it consistently to both
TracerProvider and LoggerProvider.
- Keep the existing private entry points working (or alias them) during the transition.
cc @aabmass @herin049
What
Provide a public API to set logger (and, for consistency, tracer) configuration programmatically at runtime, so users can enable/disable a logger or adjust its config without relying on the private
_-prefixed API.Background
PR #5380 wires
Logger.enabled()to consultLoggerConfig.is_enabled. The configuration itself is already settable programmatically today, but only through private API:_LoggerConfig(is_enabled=...)LoggerProvider._set_logger_configurator(logger_configurator=...)/ the_logger_configuratorconstructor argumentThis came up in review on #5380 (#5380 (comment)), where the question was raised that it should eventually be possible to set this via a public API.
Why this is a separate change
The tracer side is the template for this code and is also still private (
_TracerConfig,TracerProvider._set_tracer_configurator). Promoting logger config to a public API in isolation would diverge the two signals. This should be a deliberate, consistent cross-signal decision (traces and logs, and any future signal), so it does not belong inside theenabled()PR.Proposed scope
TracerProviderandLoggerProvider.cc @aabmass @herin049