## Motivation
As discussed in #308, there are a large number of crates in this
repository, which can be confusing for users and can increase the
maintainance burden for maintainers. Also, the `tracing-fmt` and
`tracing-subscriber` crates both contain filtering implementations with
similar behaviour and APIs, but `tracing-subscriber`'s filter module
offers more advanced features (filtering on field values), and is usable
with any subscriber implementation. Two separate filter implementations
also has the potential to be confusing for users.
## Solution
This branch moves most of the code from `tracing-fmt` into a module in
`tracing-subscriber`, and changes the `tracing-fmt` builder APIs to use
the `Filter` type in `tracing-subscriber`. The `tracing-subscriber/fmt`
feature flag can be used to disable the formatting subscriber when it is
not used.
The `tracing-fmt` crate has been updated to re-export the APIs from
`tracing-subscriber`, and marked as deprecated. Once we've published a
new version of `tracing-subscriber` with the format APIs, we can publish
a final release of `tracing-fmt` that will update the documentation &
mark all APIs as deprecated, so that users know to move to the
`tracing-subscriber` crate.
Refs: #308
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
`tracing` is built with Rust's 2018 edition, but some examples use
outdated idioms. Ideally, examples would show code using the currently
preferred idioms. This improves clarity, especially for newer Rust
programmers who may not be familiar with the idioms of earlier editions.
## Solution
This branch updates all the examples to use Rust 2018 edition idioms,
and adds `deny` attributes to prevent the use of outdated idioms.
* deny rust 2018 idiom lints in examples
* examples: update to use Rust 2018 idioms
* examples: remove most uses of `extern crate`
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
The `tracing-tower` crate for compatibility with `tower` is currently
pretty half-baked and incomplete, and doesn't conver a majority of
use-cases.
## Solution
This branch completely rewrites the `tracing-tower` support crate,
hopefully making it more useful.
We now provide a set of `request_span` middleware for instrumenting a
service so that each request passing through it is instrumented with its
own span, and a set of `service_span` metadata that instruments the
entire service with a single span. Additionally, there are now
implementations of `Layer` and `MakeService`, when the `tower-layer` and
`tower-util` crates are also in use. Finally, I've reworked the
`InstrumentableService` extension trait a bit to make it easier to
implement services in different ways, although the old behaviour of
`InstrumentableService::instrument` is unchanged (I've heard
@LucioFranco is using this in prod...).
Most of the functionality of the `tracing-tower-http` crate can now be
reimplemented using the new `tracing-tower` crate (and a feature-flagged
`http` dependency), so that crate should _probably_ now be deprecated.
I've reimplemented its example using `tracing-tower`.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
