Repository: tokio-rs/tracing (Rust)

Issue:
Re-export necessary log types from `tracing-log`
## Feature Request

### Crates

tracing-log

### Motivation

In a project that uses tracing, a dedicated dependency on `log` should not be needed.

1. Not having the dependency avoids developers from accidentally using `log` instead of `tracing`.
2. `tracing-log` depends on a certain version of `log`. In order to call the fn `LogTracer::init_with_filter`, these dependencies need to match.

### Proposal

Re-export either the whole `log` crate from `tracing-log` or at the very minimum, all types that appear in public APIs.

### Alternatives

Leave everything as it is, requiring users to explicitly depend on `log`.


Discussion:
This seems like it could be a good idea. The one downside is that if `log` issues a breaking change, we may have to issue a breaking change for `tracing-log` as well...although, if we change the version we depend on to one with a breaking change, that's kind of already the case...

@tokio-rs/tracing any thoughts on this?
Yeah, I think this is a good idea.

> The one downside is that if log issues a breaking change, we may have to issue a breaking change for tracing-log as well...although, if we change the version we depend on to one with a breaking change, that's kind of already the case...

Given how conservative `log` is in cutting _any_ releases, I'm not too worried about a mismatch in release cadence.
> ...although, if we change the version we depend on to one with a 

@hawkw that is the point yes :)

Slightly off-topic: I would really wish, [this lint](https://github.com/rust-lang/rust-clippy/issues/3553) would get more attention.
IMO, it is a huge issue in the Rust ecosystem: Too many crates have external types in their public API and don't reexport them, forcing downstream users to manually add a dependency on the crate and keeping the version in sync as those dependencies are upgraded.
@thomaseizinger that motivation makes sense — I'm definitely on board with this. If you're interested in opening a PR to add the re-exports, I'd happily merge it. Otherwise, I'm fine with adding it when I get around to it.



Patch:
diff --git a/tracing-log/src/lib.rs b/tracing-log/src/lib.rs
index 351f3da576..98f86024c9 100644
--- a/tracing-log/src/lib.rs
+++ b/tracing-log/src/lib.rs
@@ -151,6 +151,8 @@ pub use self::trace_logger::TraceLogger;
 #[cfg_attr(docsrs, doc(cfg(feature = "env_logger")))]
 pub mod env_logger;
 
+pub use log;
+
 /// Format a log record as a trace event in the current span.
 pub fn format_trace(record: &log::Record<'_>) -> io::Result<()> {
     let filter_meta = record.as_trace();


Test patch:
diff --git a/tracing-log/tests/reexport_log_crate.rs b/tracing-log/tests/reexport_log_crate.rs
new file mode 100644
index 0000000000..1540941f2f
--- /dev/null
+++ b/tracing-log/tests/reexport_log_crate.rs
@@ -0,0 +1,10 @@
+use tracing_log::{log::LevelFilter, LogTracer};
+
+/// This test makes sure we can access `log::LevelFilter` through the `tracing_log` crate and don't
+/// have to depend on `log` separately.
+///
+/// See https://github.com/tokio-rs/tracing/issues/552.
+#[test]
+fn can_initialize_log_tracer_with_level() {
+    LogTracer::init_with_filter(LevelFilter::Error).unwrap();
+}