Improve logging #7
Conversation
| #[cfg(all(feature = "log", feature = "log-tracing"))] | ||
| compile_error!("Features `log-tracing` and `log` cannot be enabled together"); | ||
|
|
||
| #[cfg(all(not(feature = "log"), not(feature = "log-tracing")))] |
There was a problem hiding this comment.
Both log and tracing have forwarding facades, so both are interchangable if someone wants to use library other than we are.
Given that tracing became de-facto standard and just much better due to opentelemetry compatibility (Spans, log attributes, e.t.c), I think we should drop log support, and leave only tracing here.
| #[cfg(all(feature = "log", not(feature = "log-tracing")))] | ||
| pub use log::{debug, info, warn, error}; | ||
|
|
||
| pub const LOG_TARGET: &str = "chainql"; |
There was a problem hiding this comment.
I don't think we necessarily need to have stable log target name (Honestly, polkadot-sdk in many cases too, it would've benefit from log granularity), the defaults (module name, e.g chainql_core::rebuild) are fine.
| } | ||
|
|
||
| info!(target: LOG_TARGET, "preloaded {keys_count} keys ({left} left)"); |
There was a problem hiding this comment.
If we really want to have nice output, we can use tracing spans here, then we can just use https://github.com/emersonford/tracing-indicatif for visualising span progress.
Leave it as-is for now.
|
Also, there are conflicts with trunk |
Этот PR заменяет eprintln! логи на стандартные tracing и log. По-умолчанию активировано логирование через tracing, но также существует опциональная возможность логировать через log для проекта PyChainql