`level_for_module` level-filtering for modules, not targets

[daboross]

Some producers, such as tracing, don't have useful information in the log target, but do populate the log module: see https://github.com/daboross/fern/issues/85.

While filtering based on target should be the default, could we do a separate filter for the module?

Note: it should be well-documented that this does not in interact with the shortest-first hierarchy of target filtering, and doesn't respect info!(target: "events", "echo")-style targets.

I think we could also improve the docs for level_for by using info!(target:..., ...) as an example to demonstrate the difference between targets and modules.

[cdesch]

@daboross is there a way to get fern to work with tracing in the meantime?

[cdesch]

I get the error Error: SetLoggerError(()) when trying to use fern with tracing:

cj@cj-Z:~/projects/macro_sandbox|main ⇒  RUST_BACKTRACE=full cargo run                             
   Compiling macro_sandbox v0.1.0 (/home/cj/projects/macro_sandbox)
    Finished dev [unoptimized + debuginfo] target(s) in 1.11s
     Running `target/debug/macro_sandbox`
Hello, world!
Error: SetLoggerError(())
cj@cj-Z:~/projects/macro_sandbox|main ⇒  

Here is a repo that reproduces the error.

Is this error related to the targets for module level filtering? I think this might be related to this issue: https://github.com/tokio-rs/tracing/issues/1237 in tracing

[daboross]

@daboross is there a way to get fern to work with tracing in the meantime?

No, not at the moment. I would say to use Dispatch::filter, but log::Metadata only exposes the target, not the originating module.

We might be able to get a fix in on tracing's side, if the fact that they overwrite the target with their own internal one is a bug, rather than a feature. But I haven't tried to contact them about it.

Is this error related to the targets for module level filtering? I think this might be related to this issue: tokio-rs/tracing#1237 in tracing

This is unrelated - looks like it was solved in discussion with the other issue, though! Agreed with the notgull's comment there - it looks like a conflict for the global logger - there can be only one.

You may be able to get this to work without modifications if you can set up fern to receive only messages from tracing-subscriber? I don't know their API too well, but on ferns side at least, it doesn't need to be the global logger.

If you use let (global_level, log) = dispatch.into_log(); instead of .apply() as the final transformation in fern, you'll get a boxed logger which you can feed log entries to put through into fern. It won't consume logs globally anymore, but if you can then set up tracing-log to be registered globally, and forward log entries from that or tracing-subscriber into the fern logger, then both could co-exist.