RFC: Logging: enable configuration via ENV #26265
Conversation
vtjnash
force-pushed
the
jn/logging-by-env
branch
from
99df6a4
to
77153cc
Compare
|
Sweet! |
vtjnash
force-pushed
the
jn/logging-by-env
branch
from
77153cc
to
603d508
Compare
|
IMHO, configuring logging based on environment variables might not be the best (or most maintainable) approach. |
|
Since we currently have no obvious way to configure and use logging and little to no documentation on how to do so, this seems like a vast improvement. |
|
Seems like we should address the lack of logging configuration options and documentation instead, but I guess if we aren't concerned about needing to maintain this functionality then that's fine for now. |
|
I don't really see what's so bad about having an environment variable in addition to other ways to control logging. |
|
I like the functionality this brings, but I think the implementation should live in the I've got a branch where I've been struggling with logger configuration and more flexible filtering to address more or less the same problems (see also #25404). Let me clean that up and create a PR which we can compare. Regarding documentation, see #26005 which is basically complete (it's not merged as it got sidetracked into design rather than just documenting what's done). |
|
I'll admit that I don't see any reason for |
|
Yep, expecting each logger to reimplement filtering in a compatible way is a problem, which is why I'm struggling with the logger configuration design. But I don't think that means we need to bake all this into The |
What? It absolutely should depend on global state. That's the entire point of this PR. |
vtjnash
force-pushed
the
jn/logging-by-env
branch
from
603d508
to
1510f13
Compare
|
Any movement here? I've been gradually moving my package's logging over to Logging, but it really needs a knob to enable per-module debug messages. |
|
I'm tempted to run this through CI again and just merge it. Other means of tweaking log output can be added in the future, but the lack of any way to do this now is a bit of a problem. |
This restores the functionality we had previously to set JULIA_DEBUG_LOADING=1 to activate logging; now the equivalent would be to set JULIA_DEBUG=loading. But with the new infrastructure, this is also generalized to allow filtering on any key (module, root-module, or filename), or "all". This sits between the global disable (which still provides a fast-path to skip everything), and the default min-level for a logger (which will be overridden by the environment variable). This also tries to move a bit more work into non-inlined helper functions, rather than inlining that code directly, to slightly reduce the size of the emitted code. As a possible future improvement, we could allow specifying specific levels (such as `loading=MaxLevel` or `all=Debug`), to provide even more fine-grained control. fix #25549
vtjnash
force-pushed
the
jn/logging-by-env
branch
from
1510f13
to
9a0864e
Compare
|
CI looks good, with only circle failing to OOM during build. |
This restores the functionality we had previously to set JULIA_DEBUG_LOADING=1 to activate logging;
now the equivalent would be to set JULIA_DEBUG=loading. But with the new infrastructure, this is also
generalized to allow filtering on any key (module, root-module, or filename), or "all".
This sits between the global disable (which still provides a fast-path to skip everything),
and the default min-level for a logger (which will be overridden by the environment variable).
This also tries to move a bit more work into non-inlined helper functions,
rather than inlining that code directly, to slightly reduce the size of
the emitted code.
As a possible future improvement, we could allow specifying specific
levels (such as
loading=MaxLevelorall=Debug), to provide even morefine-grained control.
I know this needs-docs, but Logging doesn't currently appear to have any, so I have nowhere to put them :(
fix #25549