Logger Composability Guidelines #267

New issue

Open

opened 2018-04-07 13:30:25 -05:00 by mitsuhiko · 6 comments

mitsuhiko commented

2018-04-07 13:30:25 -05:00

(Migrated from github.com)

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.

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](https://github.com/getsentry/sentry-rust) 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.

sfackler commented

2018-04-07 16:00:47 -05:00

(Migrated from github.com)

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 Log impl in addition to the direct init convenience methods, yeah.

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 `Log` impl in addition to the direct init convenience methods, yeah.

sfackler commented

2018-04-08 15:15:34 -05:00

(Migrated from github.com)

One interesting question is who should control the max log level. Should the Log implementation's constructor set it up, or is that the job of whoever's using it?

One interesting question is who should control the max log level. Should the `Log` implementation's constructor set it up, or is that the job of whoever's using it?

mitsuhiko commented

2018-04-09 02:38:30 -05:00

(Migrated from github.com)

@sfackler i do wonder if it wouldn't make sense to have the Log have 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 i do wonder if it wouldn't make sense to have the `Log` have 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 commented

2018-04-09 16:33:45 -05:00

(Migrated from github.com)

That would handle part of it, but there's still the case where the logger is reconfiguring itself at runtime.

dpc commented

2018-05-03 18:16:06 -05:00

(Migrated from github.com)

In slog loggers (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.

In `slog` loggers (which are called Drain) [impl a trait](https://docs.rs/slog/2.2.3/slog/trait.Drain.html). That seems like an idiomatic way to do it. This way they can be generalized over, composed, etc.

KodrAus commented

2021-11-15 01:24:13 -06:00

(Migrated from github.com)

It's been a long time here. slog and log4rs have always offered a complete API for building logging pipelines, and libraries like tracing have 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 in log, but I think the universal advice is for libraries implementing Log to expose concrete types that callers can construct and work with directly.

It's been a long time here. `slog` and `log4rs` have always offered a complete API for building logging pipelines, and libraries like `tracing` have 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 in `log`, but I think the universal advice is for libraries implementing `Log` to expose concrete types that callers can construct and work with directly.