Repository navigation
Logger Composability Guidelines #267
Description
This is not necessarily a feature request but maybe a request for guidelines. Currently a lot of crates provide something like try_init or init where a logger is set as the global handler. As there can only be one it means that once that happens nobody can change it (unlike for instance the panic hook which can be overridden).
As a result crates like sentry that want to get logger data in addition to dispatching to another logger run into the issue where the user needs to completely change their code to get it hooked. For instance the pretty_env_logger and many others do not even provide a convenient way to say "get me a logger with default config" but don't register it.
Would it make sense to encourage loggers to provide a standardized API that returns a logger but does not register it? A similar issue also happens with the global level where users themselves need to figure out what the highest level is that multiple loggers might need.
Activity
sfackler commentedon Apr 7, 2018
I think it would make sense to update the "implementing a logger" section of the docs to say that you should provide a constructor for your
Logimpl in addition to the direct init convenience methods, yeah.sfackler commentedon Apr 8, 2018
One interesting question is who should control the max log level. Should the
Logimplementation's constructor set it up, or is that the job of whoever's using it?mitsuhiko commentedon Apr 9, 2018
@sfackler i do wonder if it wouldn't make sense to have the
Loghave a new trait method that returns the global log level as option and if one is returned then it's being set when the logger is registered.sfackler commentedon Apr 9, 2018
That would handle part of it, but there's still the case where the logger is reconfiguring itself at runtime.
dpc commentedon May 3, 2018
In
slogloggers (which are called Drain) impl a trait. That seems like an idiomatic way to do it. This way they can be generalized over, composed, etc.KodrAus commentedon Nov 15, 2021
It's been a long time here.
slogandlog4rshave always offered a complete API for building logging pipelines, and libraries liketracinghave also since come along and scaffolded out a lot of API work in this area. I don't imagine we'd want to replicate much of that here inlog, but I think the universal advice is for libraries implementingLogto expose concrete types that callers can construct and work with directly.Merge pull request rust-lang#276 from NobodyXu/fix