<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">And ultimately that would be the way to go, as we evolve our logging support.</div><div class=""><br class=""></div><div class="">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 <i class="">more</i> detail - albeit, logged at level debug1 or lower - to help with troubleshooting.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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!</div><div class=""><br class=""></div><div class="">Thoughts?</div><div class=""><br class=""></div><div class=""><div><br class=""><div class=""></div></div><blockquote type="cite" class=""><div><div class="">On 2021-06-01-T, at 19:29, Joshua Root <<a href="mailto:jmr@macports.org" class="">jmr@macports.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="">On 2021-6-2 09:05 , Rainer Müller wrote:<br class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class="">On 24/05/2021 17.13, Christopher Nielsen wrote:<br class=""></blockquote><blockquote type="cite" class="">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.<br class=""><br class="">I’ve found this extremely helpful in the various projects I’ve worked on over the years. And it would certainly benefit us too.<br class=""><br class="">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?)<br class=""><br class="">But naming aside, has anyone else considered the general idea? Thoughts?<br class=""></blockquote>I would see it from another perspective. Why skip verbose mode and go<br class="">straight to debug mode? If more information is regularly required,<br class="">shouldn't we instead move more log messages to verbose mode instead of<br class="">hiding them in the debug log only?<br class=""></blockquote><br class="">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.<br class=""><br class="">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.<br class=""></div></div></blockquote></div></body></html>