-
Notifications
You must be signed in to change notification settings - Fork 734
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Manually creating a Directive
for a specific target
#2507
Comments
Additionally: Is there a way to add a directive before the env, as adding them afterwards override, even the existing directive (from env) is more verbose? Short exerpt from let mut builder = env_logger::builder();
builder.filter_level(LevelFilter::Info);
for (level, modules) in MODULES {
for module in *modules {
builder.filter_module(module, *level);
}
}
builder.parse_default_env().try_init()?; |
Would a PR be appreciated? |
I would be happy to merge a pull request for programmatically creating directives --- this has been discussed previously a bit in #404, so you may want to look at that issue as well. There is also a builder API for
There is already a builder API for |
Alright, that sounds like a good idea |
\## Motivation 1. There are some filters which can not be created with the current Directive string repr syntax, like e.g. the strings `bool`, `1` or `2.3` or values containing characters including but not limited to `}],` (for some of this there are partial fixes in other PRS). Furthermore updating the syntax the accomadate this is always a potential braking change, one which also can be subtle to detect. 2. Sometimes there is need to create `Directives` progrematically, e.g. from a different kind of logging config or to set more complicated defaults. 3. We might want to add other matching capabilities in the future which might not be representable in the string syntax (or at least entail a braking change). Like e.g. matching fields regex, matching based on `dyn Value`, a field matching the string `true` and boolean `true` at the same time, etc. By allowing programatic creation of `Directive`s we allow downstream users to work around existing issues, experiement with solution to such issues in external crates and in addition set the fundation for adding future matching capabilities in the future. \## Solution - adds `Directive::builder()` / `DirectiveBuilder` - `ValueMatch` is now public, but wrapped to that we can freely extend and change it without braking changes Workaround For: tokio-rs#1181 Fixes: tokio-rs#2507, tokio-rs#404 Refs: tokio-rs#3016, tokio-rs#1584, tokio-rs#1181
Motivation ---------- 1. There are some filters which can not be created with the current Directive string repr syntax, like e.g. the strings `bool`, `1` or `2.3` or values containing characters including but not limited to `}],` (for some of this there are partial fixes in other PRS). Furthermore updating the syntax the accomadate this is always a potential braking change, one which also can be subtle to detect. 2. Sometimes there is need to create `Directives` progrematically, e.g. from a different kind of logging config or to set more complicated defaults. 3. We might want to add other matching capabilities in the future which might not be representable in the string syntax (or at least entail a braking change). Like e.g. matching fields regex, matching based on `dyn Value`, a field matching the string `true` and boolean `true` at the same time, etc. By allowing programatic creation of `Directive`s we allow downstream users to work around existing issues, experiement with solution to such issues in external crates and in addition set the fundation for adding future matching capabilities in the future. Solution -------- - adds `Directive::builder()` / `DirectiveBuilder` - `ValueMatch` is now public, but wrapped to that we can freely extend and change it without braking changes Workaround For: tokio-rs#1181 Fixes: tokio-rs#2507, tokio-rs#404 Refs: tokio-rs#3016, tokio-rs#1584, tokio-rs#1181
Motivation ---------- 1. There are some filters which can not be created with the current Directive string repr syntax, like e.g. the strings `bool`, `1` or `2.3` or values containing characters including but not limited to `}],` (for some of this there are partial fixes in other PRS). Furthermore updating the syntax the accomadate this is always a potential braking change, one which also can be subtle to detect. 2. Sometimes there is need to create `Directives` progrematically, e.g. from a different kind of logging config or to set more complicated defaults. 3. We might want to add other matching capabilities in the future which might not be representable in the string syntax (or at least entail a braking change). Like e.g. matching fields regex, matching based on `dyn Value`, a field matching the string `true` and boolean `true` at the same time, etc. By allowing programatic creation of `Directive`s we allow downstream users to work around existing issues, experiement with solution to such issues in external crates and in addition set the fundation for adding future matching capabilities in the future. Solution -------- - adds `Directive::builder()` / `DirectiveBuilder` - `ValueMatch` is now public, but wrapped to that we can freely extend and change it without braking changes Workaround For: tokio-rs#1584, tokio-rs#1181 Fixes: tokio-rs#2507, tokio-rs#404 Refs: tokio-rs#1584, tokio-rs#1181
Motivation ---------- 1. There are some filters which can not be created with the current Directive string repr syntax, like e.g. the strings `bool`, `1` or `2.3` or values containing characters including but not limited to `}],` (for some of this there are partial fixes in other PRS). Furthermore updating the syntax the accommodate this is always a potential braking change, one which also can be subtle to detect. 2. Sometimes there is need to create `Directives` programmatically, e.g. from a different kind of logging config or to set more complicated defaults. 3. We might want to add other matching capabilities in the future which might not be re presentable in the string syntax (or at least entail a braking change). Like e.g. matching fields regex, matching based on `dyn Value`, a field matching the string `true` and boolean `true` at the same time, etc. By allowing programmatic creation of `Directive`s we allow downstream users to work around existing issues, experiment with solution to such issues in external crates and in addition set the foundation for adding future matching capabilities in the future. Solution -------- - adds `Directive::builder()` / `DirectiveBuilder` - `ValueMatch` is now public, but wrapped to that we can freely extend and change it without braking changes Workaround For: tokio-rs#1584, tokio-rs#1181 Fixes: tokio-rs#2507, tokio-rs#404 Refs: tokio-rs#1584, tokio-rs#1181
Motivation ---------- 1. There are some filters which can not be created with the current Directive string repr syntax, like e.g. the strings `bool`, `1` or `2.3` or values containing characters including but not limited to `}],` (for some of this there are partial fixes in other PRS). Furthermore updating the syntax the accommodate this is always a potential braking change, one which also can be subtle to detect. 2. Sometimes there is need to create `Directives` programmatically, e.g. from a different kind of logging config or to set more complicated defaults. 3. We might want to add other matching capabilities in the future which might not be re presentable in the string syntax (or at least entail a braking change). Like e.g. matching fields regex, matching based on `dyn Value`, a field matching the string `true` and boolean `true` at the same time, etc. By allowing programmatic creation of `Directive`s we allow downstream users to work around existing issues, experiment with solution to such issues in external crates and in addition set the foundation for adding future matching capabilities in the future. Solution -------- - adds `Directive::builder()` / `DirectiveBuilder` - `ValueMatch` is now public, but wrapped to that we can freely extend and change it without braking changes Workaround For: tokio-rs#1584, tokio-rs#1181 Fixes: tokio-rs#2507, tokio-rs#404 Refs: tokio-rs#1584, tokio-rs#1181
Feature Request
The ability to manually create a Directive with a
target
.It is currently only possible to construct a Directive without a specific target using
From<Level>
Crates
Motivation
This would allow adding more specific filtering directives to the
EnvFilter
programmatically, to for example silence chatty crates.Using
Targets
is not possible as it only provides a subset of theEnvFilter
functionality, as well as not ordering the directives by specificity, using theEnvFilter
is preferable.Proposal
Alternatives
Using the more limited
Targets
which allow foradd_directive(target, level
:This doesn't work for
RUST_LOG=info
sinceiter
only returns forSome(targets)
, so "general" directives will be missed.Doing it the other way:
does not work with
RUST_LOG="my_crate=debug
since themy_crate=info
will be ordered beforemy_crate=debug
in theDirectiveSet
due to stable sorting.The text was updated successfully, but these errors were encountered: