flowchartsman commented on issue #1078:
URL:
https://github.com/apache/pulsar-client-go/issues/1078#issuecomment-1680725466
> Besides, how do you compare among logrus, zap and the new slog? Are they
functionally different? Or just we'd prefer a solution out of the box from
stdlib.
It's less about functionality, and more about future-proofing, since there
will now be standard types that can serve as a compatibility layer without
forcing a non-stdlib dependency for implementation. Right now, there are some
difficulties I have with the standard logger, where I'm kind of locked in to
how I deal with them:
- logs are on by default, and an explicit nop logger must be provided to
disable them
- Default logging is very chatty, but there's no option to simply set a
threshold for this without another logger implementation or using the nop
logger to turn it off completely
- Package logs display in a format I don't want to use.
If I want to change any of these things, I must implement the entire
interface, including more complex methods such as `SubLogger`, `WithFields`,
`WithField`, and `WithError`, which return the `log.Logger` and `log.Entry`
types, which means a dependency on `pulsar-client-go`. Or I have to use logrus
with the wrapper, forcing me to have a dependency on logrus.
If the library takes a `slog.Handler` or a `slog.Logger`, I can set the
threshold and formatting I want on these, and the interface is well understood
and can be connected with anything that supports `slog`. or will in the future,
since it is likely that future packages will at least have to provide a `slog`
compatibility layer, which means easier interaction.
> IIRC pulsar-client-go still supports Go 1.15. What do you think of the
migrating plan? As long as we declare to support versions before 1.21, we
cannot fully adopt the slog solution.
This issue has two parts: support for Go versions and semver compatibility
on `pulsar-client-go`
As far as semver goes, change to the logging interface would have to wait
for a major revision number. I don't know if there are any plans to move to
`1.0` ever, but that would be the time to do it. Or if this package ever moves
to major version mirroring for `pulsar`, that would also be an opportunity. If
there is any roadmap to the next major version, I wanted to get a tracking
issue here, since that should definitely be on it.
With Go versions, I think that it is okay to follow the support lifecycle of
Go itself, which means two minor versions. That would currently put us at 1.20.
1.19 and older are EOL as far as Go is concerned. With the compatibility
promise, it does not make much sense to declare explicit support for older
versions. This at least opens up the possibility to support `slog` types as
additional options without changing the primary logging interface once go1.21
is the oldest supported version.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
