Use injected Logger instead of logrus.Entry in library

[dihedron]

Hi @dselans,
the library uses logrus and therefore introduces a dependency on a specific logging package, which is quite unfortunate for a library. I don't want to thrust a different logging library upon you and it's easy to fork the library and remove the logging lines, but maybe I can help you:

1. either to remove the three or four lines that log messages that seem to be more for debugging purposes than anything else, and free the library from the dependency;
2. or to make this more of a library while still being able to use logrus if you need so by implementing the following.

PROPOSAL:

Unfortunately the stdlib's log.Logger is a struct and not an interface. But it would still be possible to have our definition of an interface :

package rabbit

// Logger is a common interface for loggers
type Logger interface {
   Debug(args ...interface{})
   Debugf(format string, args ...interface{})
   Info(args ...interface{})
   Infof(format string, args ...interface{})
   Warn(args ...interface{})
   Warnf(format string, args ...interface{})
   Error(args ...interface{})
   Errorf(format string, args ...interface{})
   Fatal(args ...interface{})
   Fatalf(format string, args ...interface{})
}

and then let the library clients inject their favourite logger via an additional Log field in the Options:

// Options determines how the `rabbit` library will behave and should be passed
// in to rabbit via `New()`. Many of the options are optional (and will fall
// back to sane defaults).
type Options struct {
	// Required; format "amqp://user:pass@host:port"
	URLs []string

	// In what mode does the library operate (Both, Consumer, Producer)
	Mode Mode
        [...]
        Log Logger // this is a rabbit.Logger interface

The caller will have to provide a logger that implements the interface, or wrap it. This would make it easy to swap in a different logging library (e.g. Uber's zap, which performs really well and supports structured logging), or none at all if no logging is needed.

Please let me know if you're interested; i can submit a PR if you like the idea (but please specify which option you prefer: I would go for no 1.)

Cheers!

[dselans]

@dihedron let's roll with Option 2 - it's a familiar pattern that is present in many libs. The interface and approach you presented makes sense.

[dihedron]

Cool.

[dselans]

Thanks for the PR @dihedron !