I have written some code (which performs bash operations) that can be executed via a CLI bin (to directly use the features of my code) and can also be used as a library.
When my code is executed via the CLI interface, My logs are printed as INFO. But when my code is executed via the library, it might be more appropriate (depending on the user, but according to my use) for these same logs to be DEBUG (and with different formatting).
I imagine I can create a different formatter depending on the use of the bin/lib (with features?). And encapsulate logging behind mechanisms that change INFO/DEBUG based on a parameter.
But I guess this is a common case. And maybe there is a pattern for this?
Ideally your library only uses the log crate to log events on appropriate levels and only the implementing binary chooses the actual logger implementation, such as env_logger and thus the level.
Also your crate should not include both, the library and the binary. I recommend to split the crate into a workspace instead which contains two separate crates, the library and the binary using the library.
It's from the tokio/tower async stack ecosystem, but the integration there is only in a separate instrumentation crate.
The relevant part here is you only emit whatever events you like at whatever levels make sense in your library, then a binary can configure whatever logging makes sense: filtering by crate, level, or arbitrary metadata, formatting as text or JSON or sending off to some logging service..., it's perhaps overly configurable which leads to some complicated code if you're doing something interesting.