options.Logger is incompatible to slog logger

[TLINDEN]

I am using the slog logger and wanted to enable the new Options.Logger feature, which fails:

lg := slog.Default()
opts.Logger = *lg
db, err := bolt.Open(db.Dbfile, 0600, opts)

Compilation fails:

cannot use *lg (variable of type slog.Logger) as bbolt.Logger value in assignment: slog.Logger does not implement bbolt.Logger (method Debug has pointer receiver)

So, in order to be able to use my existing logger setup, I'd have to implement a bolt.Logger wrapper around the slog logger.

I'd appreciate it, if slog would be supported directly.

best,
Tom

[ivanvc]

We covered this in the fortnightly etcd triage meeting. In #509, the decision was to implement a logger interface compatible with go.uber.org/zap.

I'm torn because implementing a bridge/wrapper struct for every existing logger doesn't make sense and may quickly become an issue. However, log/slog is part of Golang's stdlib.

The bridge/wrapper is pretty simple:

import (
        "fmt"
        "log/slog"

        bolt "go.etcd.io/bbolt"
)

type logger struct {
        *slog.Logger
}

func (l logger) Debug(v ...interface{})                   {}
func (l logger) Debugf(format string, v ...interface{})   { l.Logger.Debug(fmt.Sprintf(format, v...)) }
func (l logger) Error(v ...interface{})                   {}
func (l logger) Errorf(format string, v ...interface{})   { l.Logger.Error(fmt.Sprintf(format, v...)) }
func (l logger) Info(v ...interface{})                    {}
func (l logger) Infof(format string, v ...interface{})    { l.Logger.Info(fmt.Sprintf(format, v...)) }
func (l logger) Warning(v ...interface{})                 {}
func (l logger) Warningf(format string, v ...interface{}) { l.Logger.Warn(fmt.Sprintf(format, v...)) }
func (l logger) Fatal(v ...interface{})                   {}
func (l logger) Fatalf(format string, v ...interface{})   { l.Logger.Error(fmt.Sprintf(format, v...)) }
func (l logger) Panic(v ...interface{})                   {}
func (l logger) Panicf(format string, v ...interface{})   { l.Logger.Error(fmt.Sprintf(format, v...)) }

func main() {
        lg := logger{slog.Default()}
        db, err := bolt.Open("test.db", 0600, &bolt.Options{Logger: lg})
        ...
}

Note that we only use the *f (formatted) functions. So, the implementation for the functions that don't receive a format can be empty.

I believe it would make more sense to document rather than implement it. What do you think, @ahrtr?

[ahrtr]

We don't want to manage any specific logger, nor their configuration. It's the reason why we only expose an interface.

Also exp/slog was experimental when we started to add logger into bbolt. But it's part of the golang std lib (starting from go1.21) now.

It's definitely better to enhance the document at least at https://pkg.go.dev/go.etcd.io/bbolt@v1.4.0#Logger.

If the community pushes hard, then I I do not object to adding thin wrappers for log/slog and go.uber.org/zap into bbolt repo, and expose interfaces something like WithSLog(...), WithUberLog(...).

[TLINDEN]

Here's one vote for it ;)

[ahrtr]

Here's one vote for it ;)

Are you voting for below comment? :)

If the community pushes hard, then I I do not object to adding thin wrappers for log/slog and go.uber.org/zap into bbolt repo, and expose interfaces something like WithSLog(...), WithUberLog(...).

[TLINDEN]

I did but to be honest, I followed the suggestion here and just implemented the logger interface. It's ok.

[PaluMacil]

The point of slog was to provide a std lib interface and allow you to use other backends besides the std lib if you want. You can see how to use uber zap here: https://github.com/samber/slog-zap

Supporting slog is not really a slippery slope to having to support more. It means you can support any logger (either by wrapper or new ones just using the std lib interface).

Something like bolt should, imho, support an interface instead of picking a specific logging library. And since the std lib provides an interface to standardize upon, I think it's the good choice. It's too bad nobody in your meeting on this had read about it before picking a specific library, but one can't know everything after all.

Hope this can be considered.

@ivanvc

[ivanvc]

Hi, @PaluMacil, thanks for your input. When the team decided what logging interface to use, slog was still experimental (refer to #509).

I don't object to adopting or doing a slog bridge. Because bbolt is a highly used dependency, I suggest not doing a breaking change (but, because v2.0.0 is the next release, you could make a point to do this as a breaking change).

We're always open to contributions, @PaluMacil. If you believe this is something the project should have, and you can submit a pull request, please feel free to do so.

Thanks again :)