How to use tracing-futures with tokio@1

[dignifiedquire]

Looking at the dependencies of tracing-futures it still pulls in tokio@0.1, but my project uses tokio@1. Aside from the inefficiency of building two versions of tokio, is there any impact on the functionality atm and is there an alternative crate I can use in the meantime?

[davidbarsky]

While tracing-futures does pull in Tokio 0.1, it does not do so by default—it is a feature that you need to directly enable. See the following output from cargo tree:

tracing-futures v0.1.0 (/Users/dbarsky/Developer/tracing-futures)
└── tracing-futures v0.2.5
    ├── pin-project v1.0.10
    │   └── pin-project-internal v1.0.10 (proc-macro)
    │       ├── proc-macro2 v1.0.36
    │       │   └── unicode-xid v0.2.2
    │       ├── quote v1.0.17
    │       │   └── proc-macro2 v1.0.36 (*)
    │       └── syn v1.0.90
    │           ├── proc-macro2 v1.0.36 (*)
    │           ├── quote v1.0.17 (*)
    │           └── unicode-xid v0.2.2
    └── tracing v0.1.32
        ├── cfg-if v1.0.0
        ├── pin-project-lite v0.2.8
        └── tracing-core v0.1.23
            └── lazy_static v1.4.0

Stepping back a little, what are you trying to accomplish? If you're trying to instrument async functions, then the tracing crate already provides this functionality through the .instrument combinator and the #[instrument] macro.

[dignifiedquire]

Thanks, I realized I actually don't need to pull it in to use .instrument. I guess my follow on question is, what are the cases I would end up needing it then?