`tracing_subscriber::fmt::SubscriberBuilder` method to access the event/field formatters

[lilyball]

Feature Request

Crates

tracing-subscriber

Motivation

I want to be able to make an extension trait on SubscriberBuilder that offers builder-style configuration of my custom event/field formatters similarly to how it has methods to configure the default formatters. This would allow me to copy the current API so my crate will be familiar to users and easy to adopt. That means having a fmt() -> SubscriberBuilder function along with adding methods to SubscriberBuilder<MyFields, MyFormat, _, _> for configuration.

Proposal

SubscriberBuilder should have methods that provide mutable access to the inner event/field formatters. This way I can configure my custom formatters. It would also allow for addition of niche configuration options on the default formatters that aren't worth adding wrapper methods to SubscriberBuilder for.

These new methods can probably eschew the builder pattern in favor of just being mutable accessors (e.g. get_mut_event_format(&mut self) -> &mut E) as they're most likely to be used by wrapper methods/functions, and any once-off use is expected to be niche.

Alternatives

#658 proposes making the event formatter own the field formatter. In this world, it's easier to configure them before giving them to the SubscriberBuilder, though that approach still won't allow for copying the default API nor is it clear if this will even happen (and if so, when it will happen).

[lilyball]

I'm also tempted to ask for something like fn map_event_format(self, f: impl FnOnce(E) -> E2) -> SubscriberBuilder<N, E2, F, W> so I can write something that needs to change the type of the formatter so I can write something equivalent to the existing

    pub fn compact(self) -> SubscriberBuilder<N, format::Format<format::Compact, T>, F, W>
    where
        N: for<'writer> FormatFields<'writer> + 'static,
    {
        SubscriberBuilder {
            filter: self.filter,
            inner: self.inner.compact(),
        }
    }

(i.e. where I can convert the formatter from one type to another while moving all the data it contains)

This is even more niche though, and I can simulate it today if need be by having my custom formatter just allow for taking data out of it (e.g. wrapping everything in Option if need be) such that my wrapper can create the new formatter from the mutable reference, drop the reference, and then call .event_format() to replace it.

[hawkw]

I'm open to adding accessors to the builders. We'll probably also want to add similar accessors to fmt::Layer, as the layer type doesn't require a separate builder but could also expose similar configuration options.

I'd happily merge a branch that adds methods of this form --- are you able to open a pull request to add them? If not, this could probably be marked as a "good first issue", since the necessary change should be fairly straightforward...

[lilyball]

Go ahead and mark it as "good first issue". I haven't found the time yet to go through my employer's approval process for contributing code and won't have the bandwidth for that in the near future for anything non-critical.

[hawkw]

That's entirely fair. Unfortunately, I also have a pretty deep queue of higher-priority tracing work, so while this is a fairly small change, I have a bunch of other small changes that are higher-impact. But, if someone has the time to work on this, I'll happily merge it.

[lilyball]

Fixed by #1871. I have no idea why GitHub didn't close this issue accordingly.

[hawkw]

Fixed by #1871. I have no idea why GitHub didn't close this issue accordingly.

I believe issues are only automatically closed when merging PRs if the PR is merged to the repository's main branch.