Gologshim runtime controlled handler

[MarcoPolo]

lidel, take a look and let me know your thoughts. This is targeting your branch.

This removes the goLogBridge interface check and having to modify the default slog logger. Instead you explicitly set the handler via gologshim.SetDefaultHandler.

[gammazero]

I think this makes the code cleaner/clearer. Your call @lidel

[lidel]

This works for us also, pushed docs + some thoughts below:

On the trade-off here

Original #3418 (commit ea2c010 before merging this PR into that one) required no changes in existing apps, just updating both go-log and go-libp2p to latest versions. That was all end user would have to do to restore logs.

This PR requires every legacy application that used both go-log and go-libp2p to add this extra code (if they use automatic slog bridge):

  import (
      "github.com/libp2p/go-libp2p/gologshim"
  )

  func init() {
      // After go-log's init() runs and installs slog bridge,
      // tell gologshim to use it      
      handler := slog.Default().Handler()      
      // Verify it's go-log's bridge
      type goLogBridge interface {
	      GoLogBridge()
      }
      if _, ok := handler.(goLogBridge); !ok {
	      panic("aborting startup: slog.Default() is not go-log's bridge, logs would be missing due to incorrect wiring")
      }
      // use the implicit go-log bridge      
      gologshim.SetDefaultHandler(handler)
  }

or this, if they dont touch slog default:

  import (
      logging "github.com/ipfs/go-log/v2"
      "github.com/libp2p/go-libp2p/gologshim"
  )

  func init() {
      // use the explicit go-log bridge      
      gologshim.SetDefaultHandler(golog.SlogHandler())
  }

If this is the price to pay to fix logs, we can do the above in Kubo, Rainbow and every other application Shipyard maintains, but everyone else will be missing logs unless they do the same.

Just a trade-off decision.

Next steps

@MarcoPolo lgtm, i've tested this PR in ipfs/kubo#11039 and it also works for us (with the above extra code).

Up to you if you prefer implicit or explicit.

• If you prefer explicit, feel free to merge this PR into #3418, and then merge that (#3419+#3418).
• If you are ok with implicit detection, this PR can be closed and only merge #3418

Either way, we would appreciate a release with a fix 🙏

[MarcoPolo]

This PR requires every legacy application that used both go-log and go-libp2p to add this extra code:

I don't follow, do you mind explaining a bit more? Where are you calling slog.SetDefault? And why not directly call gologshim.SetDefaultHandler instead?

[lidel]

@MarcoPolo I wrote an (wip draft) explainer in ipfs/go-log#176 for go-log users, check "Slog integration" section in README in that PR and especially the "For library authors" section, which has two approaches and their ramifications illustrated with sample code:

• Approach 1: Duck-typing detection (automatic)
  • this is how feat(gologshim): Add SetDefaultHandler #3418 worked for go-libp2p as well
• Approach 2: Explicit handler passing (manual)
  • this is what this PR (Gologshim runtime controlled handler #3419) implies for end users of go-libp2p (requires extra code, but still works)

Where are you calling slog.SetDefault?

go-log already called SetupLogging in own go-log's init() here to correctly handle ENV-based configuration. This already happened automatically if code imported go-log.

What we added to that init in ipfs/go-log#176 is an opt-out slog support which calls captureSlog here that sets up bridge and sets it via slog.SetDefault here

This has to be done because we dont want to lose any slog entries in go-lang apps, nor want to have different formatting from libraries that use slog. Going forward, various libraries may switch to slog, and we dont want to have regressions like the one go-libp2p caused when it switched to slog.

In the future, we may decide to switch the go-log backend from zap to slog, but the fact we call slog.SetDefault would not change. If app choses to use go-log, they expect it to handle all logs.

And why not directly call gologshim.SetDefaultHandler instead?

The go-libp2p/gologshim only takes care of go-libp2p and ignores any other application that use slog.

go-log is how applications in ecosystem control log levels and we do not want to have regressions like ipfs/kubo#11035 anywhere else.

The goal was to unbreak existing users without asking them to change any code.

If go-libp2p forces our hand to add extra call for gologshim.SetDefaultHandler to have per subsystem visibility in Kubo, that is fine, but unfortunate for turn-key experience across ecosystem. Ideally, we would not require end users to do extra work to fix every application.

[MarcoPolo]

Going forward, various libraries may switch to slog, and we dont want to have regressions like the one go-libp2p caused when it switched to slog.

Are you expecting to have all other libraries add the goLogBridge interface check? I'm not sure that makes sense.

I think setting the default log handler is something that should be owned by the application, not by a library that could possibly be a transitive dependency of another library.

I don't mind merging this change, but this will change again if/when we move away from global loggers to passing loggers explicitly. At that point applications would need to pass go-log explicitly to go-libp2p anyways, and any init trick won't work.