panic messages use keys with spaces about zapr

[pohly]

Should and can those fields be renamed?

I've not seen a recommendation how to handle keys that consist of multiple words. zapField or zap-field or ... ?

[thockin]

I don't know if zap allows us to change these. JSON allows keys with spaces, we just documented this as a convention for easiest consumption. It's probably not very consequential.

[pohly]

That's in zapr.go, our own code. We could change the keys if we wanted to.

zapr/zapr.go

Line 93 in a332506

l.DPanic("strongly-typed Zap Field passed to logr", zap.Any("zap field", args[i]))

[thockin]

I question the value of DPanic from within this lib. Disallowing zap.Field is weird. That's not our business. Input errors should not generate additional log-lines IMO, though I can see value to "panic on ill-formed log-lines in debug mode"

[thockin]

But if we DO keep it, I think it's fine to change the keys.

Watch out or you'll end up a maintainer of this :)

[pohly]

I question the value of DPanic from within this lib. Disallowing zap.Field is weird. That's not our business.

I'm on the edge myself. It breaks portability of the code which calling the logger with such a parameter, but perhaps someone doesn't care and/or wants to do it when knowing that the logger is a zap logger.

Input errors should not generate additional log-lines IMO, though I can see value to "panic on ill-formed log-lines in debug mode"

I like the idea of making those panic messages conditional on a debug flag. Then the caller can decide.

@DirectXMan12 you originally wrote that code - any thoughts on this? ^^^

But if we DO keep it, I think it's fine to change the keys.

That then begs the question: what should the non-space-using-keys be? nonSpaceUsingKeys? NonSpaceUsingKeys? We can discuss here and then extend the logr recommendations. IMHO that's actually more important than updating zapr because developers will loose time when encountering this issue without getting some guidance, for example because they start looking for prior art to remain consistent.

Watch out or you'll end up a maintainer of this :)

Who, me? I have no idea what you are talking about. 😀

[thockin]

@DirectXMan12 has found themselves mostly detached from this code, so while I welcome their input, I wouldn't block on it for too long.

nonSpaceUsingKeys? NonSpaceUsingKeys?

There's no convention that I know of. Kubernetes chose nonSpaceUsingKeys and I hate it. It has cause so many problems with Go's conventions and godoc comments. If we have to pick I'd say "NonSpaceUsingKeys" or "non-space-using-keys"

[pohly]

Kubernetes chose nonSpaceUsingKeys and I hate it.

Where was that chosen?

It has cause so many problems with Go's conventions and godoc comments

Because keys were confused with Go code, for example in search/replace? I don't like it either, I'm just trying to understand whether it is objectively worse than the alternatives.

There's no convention that I know of.

Perfect, then we can recommend something.

If we have to pick I'd say "NonSpaceUsingKeys" or "non-space-using-keys"

I like "non-space-using-keys" better because it is consistent with existing single-word keys which use lower case ("err", "v").

[thockin]

Where was that chosen?

For all of our APIs - the canonical JSON and YAML is lowercaseUppercase

Because keys were confused with Go code, for example in search/replace?

It requires every field has a json tag with the name (vector for cut-paste errors) and because comments can either be godoc compatible or useful in doc-gen but not both.

[pohly]

For all of our APIs - the canonical JSON and YAML is lowercaseUppercase

I see. I thought it was something specific to JSON message output, perhaps in the structured logging KEP or one of the associated documents. IMHO we can ignore this Kubernetes API convention for JSON log messages. Or side-step the question entirely by proposing "non-space-using-keys"... I'll submit a PR.

[pohly]

I found that Kubernetes has a recommendation for multi-word keys. You won't like it. Let's continue the discussion in go-logr/logr#65

[thockin]

Logr and zapr are not beholden to kubernetes decisions :)

…

On Wed, Aug 11, 2021, 4:54 AM Patrick Ohly ***@***.***> wrote: I found that Kubernetes has a recommendation for multi-word keys. You won't like it. Let's continue the discussion in go-logr/logr#65 <go-logr/logr#65> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#36 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKWAVGHXEU2VRHRFSB4Z4LT4JQI5ANCNFSM5BZ7WTFQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[pohly]

They are not, but conflicting recommendations put developers into an awkward spot. I'd like to see more cooperation (see zapr fork), not less.

[pohly]

We added some recommendations to logr. We could change the keys accordingly here, but strictly speaking that might be an API break for zapr v1.0.0 (it could be that someone looks for the previous values), so let's keep everything as-is here. Simpler, too...