It'd be nice to be able to use fern's manual configuration and at the same time still get an additional RUST_LOG interface with only an additional flag.
As with #60, I'm not sure if this fits the crate. I think if we reused or reimplemented only the parsing, though, we might be able to combine configurations from inside the program and from the env variable, to allow them to benefit eachother rather than replace eachother? And if we implement it as a feature flag, then it shouldn't be too much additional overhead.
I think most of that logic applies to #60 too, so implementing both might be a good idea. We could even try to accept log4rs-compatible configuration.
On the other hand, fern's configuration is infinitely recursive, and it wouldn't be entirely clear where to stick / allow the target filters. Maybe it'd have to be a method on dispatch, "allow_from_env"?
How does this scale to the file configuration, then? Does it? Not sure.
It'd be nice to be able to use
fern's manual configuration and at the same time still get an additionalRUST_LOGinterface with only an additional flag.As with #60, I'm not sure if this fits the crate. I think if we reused or reimplemented only the parsing, though, we might be able to combine configurations from inside the program and from the env variable, to allow them to benefit eachother rather than replace eachother? And if we implement it as a feature flag, then it shouldn't be too much additional overhead.
I think most of that logic applies to #60 too, so implementing both might be a good idea. We could even try to accept log4rs-compatible configuration.
On the other hand, fern's configuration is infinitely recursive, and it wouldn't be entirely clear where to stick / allow the target filters. Maybe it'd have to be a method on dispatch, "allow_from_env"?
How does this scale to the file configuration, then? Does it? Not sure.