base: logging enhancements: multiple debug output levels

[mascguy]

Per recent discussion on the dev mailing list, implement support for multiple levels of debug logging support.

Link to discussion threads:

• https://lists.macports.org/pipermail/macports-dev/2021-May/043502.html
• https://lists.macports.org/pipermail/macports-dev/2021-June/043542.html

Corresponding work for macports-ports: PR 11184 - base support: logging enhancements: multiple debug output levels

[mascguy]

Internally, levels 0-9 supported. But range 0-3 enforced via argument checks, etc.

[cjones051073]

Having 4 levels of debug seems a bit excessive to me. I would have thought that say 3 would easily be enough granularity? I also find having level ‘0’ called debug, whilst 1-3 called debugN a little confusing. I would personally suggest making debug and debug1 the same level (so just make debug an alias to debug1 for compatibility) and then have debug2 and debug3 for two increasingly more detailed levels.

[mascguy]

Having 4 levels of debug seems a bit excessive to me. I would have thought that say 3 would easily be enough granularity? I also find having level ‘0’ called debug, whilst 1-3 called debugN a little confusing. I would personally suggest making debug and debug1 the same level (so just make debug an alias to debug1 for compatibility) and then have debug2 and debug3 for two increasingly more detailed levels.

Sure, and three levels isn't set in stone; that was merely an arbitrary choice to start with.

Overall, this effort is still evolving, and the goal is to support logging based on namespaces/packages - similar to Python and Java - to allow more control over output and levels. (Per recommendations by folks on the mailing list.)

The latter hasn't been implemented yet, but watch this space.

Further thoughts/comments/suggestions welcome!

[mascguy]

Relative to namespace/package logging, I'm currently evaluating the TCL logger package, to avoid reinventing the wheel. Based on a cursory look, it may provide a nice foundation for what we're trying to accomplish.

If anyone has any experience with that package - or if there's a better option - please let me know!

[cjones051073]

Seems OK to me, thanks for this.

[cjones051073]

This doesn’t seem directly related to the debug level changes, or am I missing something ?

[mascguy]

This was necessary back a month or so ago, as the test consistently failed due to timeout. (It wasn't intended to be kept long-term though.)

Ultimately it will be reverted in this PR, or changed to use a different testing endpoint if necessary. (The latter would be based on guidance from Josh and/or Ryan.)

[cooljeanius]

hm, @jmroot @ryandesign any guidance?

[cooljeanius]

Having 4 levels of debug seems a bit excessive to me. I would have thought that say 3 would easily be enough granularity?

4 levels is how many Fink has, IIRC...

[mascguy]

This PR has been changed to ready-for-review, with the caveat that merge conflicts need to be resolved. (Will try to get to that over the next few days.)

Relative to namespace-scoped logging - something not currently included - I'm wondering if we should shelve that at this point?

Reason being, we'd need to support a way to selectively set logging levels per-namespace. (Presumably via some type of config file, such as macports.conf.) And that adds a whole new level of complexity. Not to mention the question of whether that would ever be taken advantage of.

[cooljeanius]

Relative to namespace-scoped logging - something not currently included - I'm wondering if we should shelve that at this point?

Yeah, probably worth saving that for a separate PR.