call stack skipping about logr

[pohly]

Some potential solutions:

• add additional functions like InfoDepth (as in klog)
• WithCallerSkip/WithDepth/AddCallerSkip (as in zapr)

[pohly]

I personally like WithCallerSkip best because it is more descriptive than WithDepth, consistent with WithValues (in contrast to AddCallerSkip), and avoids having to add two new functions for Info and Error.

Performance might be a concern. However, the struct that for example klogr needs to copy isn't big: https://github.com/uber-go/zap/blob/master/options.go#L108 (link from the extended klogr with two different output formats in PR kubernetes/klog#197).

I don't feel too strongly about it, though. I'm also fine with InfoDepth and ErrorDepth.

[thockin]

I acknowledge why this is useful. Not every implementation logs line numbers, but it's common enough that this matters, IMO. Whatever we do here, implementations that don't log line numbers can just ignore this.

Adding methods is somewhat ugly. I instinctively lean away from a number-of-methods multiplier like this. We star with Info/Error. Then we add InfoDepth/ErrorDepth. Then at some future point we justify something else optional, and we end up with Info, Error, InfoDepth, ErrorDepth, InfoFoo, ErrorFoo, InfoDepthFoo, ErrorDepthFoo.

Adding args to methods is a breaking change, so pretty much off the table.

Adding some sort of options pattern seems best.

I spent some time thinking about it and I don't see a cleaner answer than something like:

func DebugLog(msg string, args ...string) {
    logger.WithCallDepth(1).V(debugV).Info(fmt.Sprintf("DBG: %s", msg), args...)
}

The name is open for debate, of course. Thoughts?

[thockin]

PRs proposed

[pohly]

Adding methods is somewhat ugly. I instinctively lean away from a number-of-methods multiplier like this.

That was also my thinking.

logger.WithCallDepth(1).V(debugV)

I'm fine with that.

[pohly]

klogr implementation of WithCallDepth in https://github.com/pohly/klog/commits/klogr-call-depth