Skip to content

Determine desired behavior of logger patternSetter after switching to rapids-logger #6203

Open
@vyasr

Description

@vyasr

Currently cuml's logger supports setting a pattern in a way that is automatically reset via context management. This approach works because cuml's logger uses a single sink that is defined by cuml itself, and as a result asking for the current pattern via getPattern is well-defined. After the switch to rapids-logger in #6162, that will no longer be the case. The logger will be generalized to support an arbitrary number of sinks (like spdlog itself), meaning that there is no longer a well-defined concept of "the current pattern". While a logger can set a pattern and propagate that to all sinks, it cannot get a single pattern because different sinks could have different patterns set at any given time. As a result, in #6162 I have changed the behavior of the context to reset to the default pattern after the context completes instead of querying for a previous pattern. Once that PR merges we should decide whether that choice is acceptable, whether we want to make a different one, or if we should remove this functionality entirely in favor of a different implementation for the cases that need this sort of context management for logger patterns.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions