feat: compatibility with log/slog

[blgm]

In Go 1.21 a new structured logging package was added. This feature adds basic compatibility between lager and log/slog. This reduces the friction of mixing code that uses lager with code that uses log/slog.

[MarcPaquette]

Hi @blgm

I'm getting some failures when running the tests, could you take a look:

~/workspace/lager |blgm-slog L ✔|
$ ginkgo -r
=== RUN   TestLager
Running Suite: Lager Suite - /home/pivotal/workspace/lager
==========================================================
Random Seed: 1697726738

Will run 122 of 122 specs
••••••••••••
------------------------------
• [FAILED] [0.000 seconds]
NewSlogSink [It] logs Info()
/home/pivotal/workspace/lager/slog_sink_test.go:35

  [FAILED] Expected
      <string>:
  to match keys: {
  ."time":
        Expected
            <string>: 2023-10-19T14:45:38.259333138Z
        to match regular expression
            <string>: ^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{5,6}Z$
  }

  In [It] at: /home/pivotal/workspace/lager/slog_sink_test.go:38 @ 10/19/23 14:45:38.259
------------------------------
• [FAILED] [0.000 seconds]
NewSlogSink [It] logs Debug()
/home/pivotal/workspace/lager/slog_sink_test.go:46

  [FAILED] Expected
      <string>:
  to match keys: {
  ."time":
        Expected
            <string>: 2023-10-19T14:45:38.259838038Z
        to match regular expression
            <string>: ^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{5,6}Z$
  }

  In [It] at: /home/pivotal/workspace/lager/slog_sink_test.go:49 @ 10/19/23 14:45:38.26
------------------------------
• [FAILED] [0.000 seconds]
NewSlogSink [It] logs Error()
/home/pivotal/workspace/lager/slog_sink_test.go:57

  [FAILED] Expected
      <string>:
  to match keys: {
  ."time":
        Expected
            <string>: 2023-10-19T14:45:38.260304949Z
        to match regular expression
            <string>: ^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{5,6}Z$
  }

  In [It] at: /home/pivotal/workspace/lager/slog_sink_test.go:60 @ 10/19/23 14:45:38.26
------------------------------
• [FAILED] [0.000 seconds]
NewSlogSink [It] logs Fatal()
/home/pivotal/workspace/lager/slog_sink_test.go:69

  [FAILED] Expected
      <string>:
  to match keys: {
  ."time":
        Expected
            <string>: 2023-10-19T14:45:38.260879134Z
        to match regular expression
            <string>: ^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{5,6}Z$
  }

  In [It] at: /home/pivotal/workspace/lager/slog_sink_test.go:74 @ 10/19/23 14:45:38.261
------------------------------
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Summarizing 4 Failures:
  [FAIL] NewSlogSink [It] logs Info()
  /home/pivotal/workspace/lager/slog_sink_test.go:38
  [FAIL] NewSlogSink [It] logs Debug()
  /home/pivotal/workspace/lager/slog_sink_test.go:49
  [FAIL] NewSlogSink [It] logs Error()
  /home/pivotal/workspace/lager/slog_sink_test.go:60
  [FAIL] NewSlogSink [It] logs Fatal()
  /home/pivotal/workspace/lager/slog_sink_test.go:74

Ran 122 of 122 Specs in 0.040 seconds
FAIL! -- 118 Passed | 4 Failed | 0 Pending | 0 Skipped
--- FAIL: TestLager (0.04s)
FAIL

[winkingturtle-vmw]

I think that if we are going to add the slog compatibility, it would make sense to lock go.mod to go1.21 and remove build flags for go as well.

[blgm]

Hi @MarcPaquette, I think this is because your system is generating timestamps slightly differently. I've added a commit that will make the tests a bit more flexible in what they match. Let me know if it works for you. And if it doesn't work, feel free to hack the regular expression until it does.

@winkingturtle-vmw regarding forcing Go 1.21, that's really a trade-off of being aggressively forward looking vs supporting folks on older Go versions. When I've tried to be aggressively forward looking in the past, I've always found that there were folks who had reasons for using older versions - including versions of Go that are long out of support. So these days I look for an opportunity to make progress while breaking as few folks as possible. I don't think there's a right and wrong here, it's just a question of how you want to handle it. It's possible to support Go 1.21 functionality while maintaining support for older versions by using build flags. I agree that it's ugly. And I'm happy to make the update that you suggest, I'm just flagging that it may break a lot of folks.

[winkingturtle-vmw]

I think it's safe to lock go.mod to Go1.21. Every runtime component has been bumped to Go1.21 e.g. diego-release and that's where we use this library the most. If anyone has any other thoughts, please share. Most folks that are on older versions of this library (code.cloudfoundry.org/lager), are using the old import path and will not be getting any new updates on this repo.

[aramprice]

Any progress on merging this? Our team is working on a new component and would prefer to use Golang's slog but we have dependency on github.com/pivotal-cf/brokerapi which requires Lager.

This compatibility feature would be handy for us.

[MarcPaquette]

LGTM

[aramprice]

Thanks!

[aramprice]

Will there be a new release cut anytime soon?

[winkingturtle-vmw]

I just tagged v3.0.3 with the changes from this PR.

[blgm]

Thank you @winkingturtle-vmw and @MarcPaquette

@aramprice the slog stuff is all a bit new. I’d be interested in any feedback you have on the experience.

[aramprice]

I'll let you all know if we encounter any rough edges.

From a purely stylistic perspective it might be nice to have a one-liner option for converting. Something like:

var *slog.Logger l = codeThatReturnsSlog()

lagerLogger := lager.NewLoggerWithSink("my-lager-logger", lager.NewSlogSink(l))
// or even
lagerLogger := lager.NewLoggerFromSlog(l)

codeThatAcceptsLagerLoger(lagerLogger)