tracing_subscriber::fmt::init() vs tracing_subscriber::fmt().init()

[devmattrick]

Bug Report

Version

tracing: 0.125
tracing-subscriber: 0.2.17

❯ cargo tree | grep tracing
├── tracing v0.1.25
│   ├── tracing-attributes v0.1.15 (proc-macro)
│   └── tracing-core v0.1.17
├── tracing-subscriber v0.2.17
│   ├── tracing v0.1.25 (*)
│   ├── tracing-core v0.1.17 (*)
│   ├── tracing-log v0.1.2
│   │   └── tracing-core v0.1.17 (*)
│   └── tracing-serde v0.1.2
│       └── tracing-core v0.1.17 (*)
│   ├── tracing v0.1.25 (*)
│   │   │   └── tracing v0.1.25 (*)
│   │   │   └── tracing v0.1.25 (*)
│   │   ├── tracing v0.1.25 (*)

Platform

❯ uname -a
Linux hydrogen 4.19.128-microsoft-standard #1 SMP Tue Jun 23 12:58:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Crates

tracing-subscriber

Description

The docs for tracing_subscriber::fmt::init() state the following:

This is shorthand for

tracing_subscriber::fmt().init()

So for a basic example, I used:

use tracing::info;
use tracing_subscriber;

fn main() {
    tracing_subscriber::fmt::init();
    info!("Test");
}

This doesn't output anything in the console for me:

❯ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s
     Running `/home/matt/projects/devmattrick/test/target/debug/client`

However, using the code that this is supposed to be "shorthand" for (tracing_subscriber::fmt().init()) works fine:

use tracing::info;
use tracing_subscriber;

fn main() {
    tracing_subscriber::fmt().init();
    info!("Test");
}

❯ cargo run
   Compiling client v0.1.0 (/home/matt/projects/devmattrick/test/client)
    Finished dev [unoptimized + debuginfo] target(s) in 1.25s
     Running `/home/matt/projects/devmattrick/test/target/debug/client`
Mar 26 11:28:21.638  INFO client: Test

I'm not too sure what's causing this issue on my end, but the docs for tracing-subscriber suggest using the former to initialize everything, which doesn't work in my testing.

Add the following to your executable to initialize the default subscriber:

use tracing_subscriber;

tracing_subscriber::fmt::init();

[Folyd]

The different between (a) tracing_subscriber::fmt::init() and (b) tracing_subscriber::fmt().init() are:

• (a) depends on the env-filter feature which enabled by default
• (b) has no such feature depedence

pub fn try_init() -> Result<(), Box<dyn Error + Send + Sync + 'static>> {
    let builder = Collector::builder();

    #[cfg(feature = "env-filter")]
    let builder = builder.with_env_filter(crate::EnvFilter::from_default_env());

    builder.try_init()
}

default = ["env-filter", "smallvec", "fmt", "ansi", "chrono", "tracing-log", "json"]

This isn't a bug I think. However, we did need better documentation or keep only one init function to eliminate confusion? @hawkw @davidbarsky

[Stargateur]

That very confusing, these name are too close.

[lilyball]

Can we please fix the docs to stop claiming that fmt::init() is the same as fmt::fmt().init()? Especially now that it does more stuff when env-filter is disabled.

Heck, the extra setup it does should be pulled out into a helper. I would really love to be able to easily add that behavior to my subscriber without losing the ability to customize it further (and without having to care about the presence of env-filter myself; in my case I'm exposing a function similar to fmt() but that configures event/field formatters and I really want clients to be able to get the equivalent of tracing_subscriber::fmt::init() but with my formatters).