Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add StdLogger type #180

Closed
pkieltyka opened this issue Aug 21, 2019 · 10 comments
Closed

Add StdLogger type #180

pkieltyka opened this issue Aug 21, 2019 · 10 comments

Comments

@pkieltyka
Copy link

When building community packages, developers use a variety of loggers. It's been proposed in Go 2 to have a common Logger interface, but the below will work quite well today.

As a suggestion, it would be nice to see this code added directly to the github.com/rs/zerolog package.

or perhaps as a method on the zerolog.Logger interface, returning a StdLogger() with the interface below.. I'm happy to add a PR for this too with either approach.

package zerolog

import (
	"fmt"
	stdlog "log"
	"os"
)

// Wraps a zerolog.Logger so its interoperable with Go's standard "log" package

var _ StdLogger = &stdlog.Logger{}

type StdLogger interface {
	Fatal(v ...interface{})
	Fatalf(format string, v ...interface{})
	Print(v ...interface{})
	Println(v ...interface{})
	Printf(format string, v ...interface{})
}

func StandardLogger(log Logger) StdLogger {
	return &stdLogger{log}
}

type stdLogger struct {
	log Logger
}

func (s *stdLogger) Fatal(v ...interface{}) {
	s.log.Fatal().Msg(fmt.Sprint(v...))
	os.Exit(1)
}

func (s *stdLogger) Fatalf(format string, v ...interface{}) {
	s.log.Fatal().Msg(fmt.Sprintf(format, v...))
	os.Exit(1)
}

func (s *stdLogger) Print(v ...interface{}) {
	s.log.Info().Msg(fmt.Sprint(v...))
}

func (s *stdLogger) Println(v ...interface{}) {
	s.log.Info().Msg(fmt.Sprintln(v...))
}

func (s *stdLogger) Printf(format string, v ...interface{}) {
	s.log.Info().Msg(fmt.Sprintf(format, v...))
}
@rs
Copy link
Owner

rs commented Aug 21, 2019

Can you please link the proposal?

@pkieltyka
Copy link
Author

sure, golang/go#13182

@rs
Copy link
Owner

rs commented Aug 21, 2019

I see no conclusion on this issue and no interface agreed on.

@pkieltyka
Copy link
Author

yea, its still in proposal stage for Go 2, but you can see the direction for a standard interface. Right now you could infer a standard interface in Go v1.x by this assertion var _ StdLogger = &stdlog.Logger{} where "stdlog" is really the stdlib "log" package with an alias.

I'm good either way, as I've solved this in my code but I think it would be a nice addition to zerolog. Logrus is compatible with the above btw.. for ex,

var _ StdLogger = &logrus.Logger{} // works

@rs
Copy link
Owner

rs commented Aug 21, 2019

We already have Print and Printf on Logger. I’m open to add all the std logger methods to the main type without adding a new type. Note they should be exposed on the zerolog/log package too.

@pkieltyka
Copy link
Author

thanks @rs that would be a very nice help to clean up code in our microservices that use zerolog and integrate with community packages with the standard methods above

@dxvgef
Copy link

dxvgef commented Dec 17, 2019

Good idea! If zerolog implementslog, you can completely replace it, very much looking forward to it!

@mitar
Copy link
Contributor

mitar commented Aug 20, 2023

You can currently redirect standard log into zerolog as documented in README.

And issue #571 is about support for new structured logging interface in Golang.

But there are still some methods found in stdlog missing in zerolog (Println, Fatalf, ...). Those could be added. But the bigger issue is that some existing methods in zerolog conflict with those in stdlog. For example, Fatal() exists, but it sets the log level to fatal, it does not accept any arguments.

So sadly I do not see a way how this could be done in a backwards compatible way?

@mitar
Copy link
Contributor

mitar commented Oct 20, 2023

Println has been added in #533.

@mitar
Copy link
Contributor

mitar commented Oct 20, 2023

But Fatalf has not yet. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants