I absolutely support the package/namespace “named logger" approach. That concept is also used in the Java/.NET worlds, as well as others, and it's incredibly useful (and powerful). And since we’re already taking advantage of TCL namespaces, that provides a straightforward segregation scheme.
And ultimately that would be the way to go, as we evolve our logging support. Short-term, though, I was hoping we could start with the simpler approach: Expand our debug granularity, to filter out less-useful info by default, but without removing the detail entirely. Indeed, there are some areas where I’d like to see more detail - albeit, logged at level debug1 or lower - to help with troubleshooting. The great thing about the new levels, is that they’re complementary to package/namespace logging. So we could still add the latter down the road. As for determining what’s important at what levels, we’ll need more discussion/brainstorming. Thus far I’ve taken a stab at some suggested changes to base, as part of the PR. Though I’ve only looked at a small fraction of our current debug statements, so there’s more that could be done. Ultimately, my plan is to provide written guidelines for our members, relative to what logging level(s) to use. That would be based on thoughts/feedback from you all, and would continue to evolve as a living document. And a basic guidelines page will be delivered along with this PR. As for increasing output at our current “verbose” level, sure, that’s also a possibility. Though we might want to do that as a separate PR. I’m certainly open to any and all ideas though! Thoughts? > On 2021-06-01-T, at 19:29, Joshua Root <[email protected]> wrote: > >> On 2021-6-2 09:05 , Rainer Müller wrote: >>> On 24/05/2021 17.13, Christopher Nielsen wrote: >>> Has there been any thoughts/interest in implementing another level (or two) >>> of debug output, providing more detail than we get at Debug? That would >>> allow us to optionally output more diagnostic info in various areas, such >>> as our portgroups, without flooding the logs when running at our present >>> Debug level. >>> >>> I’ve found this extremely helpful in the various projects I’ve worked on >>> over the years. And it would certainly benefit us too. >>> >>> In many of the common logging frameworks, such a level is sometimes called >>> Trace. That terminology might be confusing within MacPorts, given that we >>> support trace mode. So perhaps we would want to name it differently. >>> (Debug2 and Debug3?) >>> >>> But naming aside, has anyone else considered the general idea? Thoughts? >> I would see it from another perspective. Why skip verbose mode and go >> straight to debug mode? If more information is regularly required, >> shouldn't we instead move more log messages to verbose mode instead of >> hiding them in the debug log only? > > For information that is routinely useful to have, I would agree. And > similarly, if there are messages that don't really convey any useful > information, they should simply be removed. > > When it comes to messages that are only wanted when debugging something, I > think it's rare that you would be able to consistently quantify how important > or unimportant a message is. Rather than a numeric debug level, it might be > more useful to be able to filter the log based on what you are trying to > debug. Someone mentioned the way Python does it earlier in the thread, and it > sounds like we could probably learn from their approach even if we don't > adopt it in full.
