Other logging frontend adapters

[MOZGIII]

Description

Looks cool! However, the code out there is already implemented with tracing and log crates - I'd like those logs to be handled ad well.

Use Case

Have one logger implementation per executable that prints the logs from the whole ecosystem of crates, not just the statements written with sheen macros explicitly.

Possible Implementation

Implement adapters for log and tracing crates; in the tracing ecosystem this is called "subscriber", don't remember how it's called in the log ecosystem...

[arferreira]

Description

Looks cool! However, the code out there is already implemented with tracing and log crates - I'd like those logs to be handled ad well.

Use Case

Have one logger implementation per executable that prints the logs from the whole ecosystem of crates, not just the statements written with sheen macros explicitly.

Possible Implementation

Implement adapters for log and tracing crates; in the tracing ecosystem this is called "subscriber", don't remember how it's called in the log ecosystem...

Hey @MOZGIII, thanks for opening this!

I'll prioritize log crate compatibility first since it's simpler and covers a lot of use cases. tracing subscriber would come after.

Would you like to take a shot at implementing either of these? Happy to help guide the approach. If not, no worries I'll pick it up soon.

[MOZGIII]

Sorry, I didn't even try sheen itself yet, so no - I won't be taking this at this time. Creating this issue is just my two cents on how to improve a crate like this further - just about all I have time for now.

[arferreira]

Sorry, I didn't even try sheen itself yet, so no - I won't be taking this at this time. Creating this issue is just my two cents on how to improve a crate like this further - just about all I have time for now.

No worries, appreciate feedback! I'll keep this open and work on log compatibility for a future release.
I'll you hit you for testing, okay?

[MOZGIII]

Not sure if I'll even do that, but please do and we'll see

Offtop

Tbh I am using tracing usually, but I'm a bit unhappy with the tracing-subscriber crate and stock facilities of it; would be nice to have something that is a one-liner to configure and allows switching log formats easily (without losing features - like mod/target filtering via the RUST_LOG env var).

That said, this crate is not that - and shouldn't try to be that.

I see it has both backend and frontend for the logging - and we do need improvements in both of those areas - but maybe they should be separate? Like, I don't really want to depend on a full logger in a lib crate - only on the frontend that I can use to place the log emits, but without pulling the whole ordeal needed for the actual logger as part of the lib crate code.

[arferreira]

@MOZGIII Implemented both adapters:

• add log crate adapter behind feature flag #4 — log crate adapter
• add tracing adapter behind optional feature flag #5 — tracing crate adapter

Both are behind optional feature flags. Would love your feedback before merging.
I also left examples so you can take a look on that as well.

[MOZGIII]

I'll check them out in a bit

[MOZGIII]

That's roughly what I had in mind, yep; might look for other things to add adapter-wise - there might be more frontends I don't know

[arferreira]

That's roughly what I had in mind, yep; might look for other things to add adapter-wise - there might be more frontends I don't know

Don't forget you're very welcome for helping me on this!