Add some helpers for using Kleisli or IOLocal for logging context#676
Add some helpers for using Kleisli or IOLocal for logging context#676wunderk1nd-e wants to merge 4 commits intotypelevel:mainfrom
Conversation
wunderk1nd-e
commented
Aug 17, 2022
- Add helpers for logging with some propagated ctx and kleisli implementation
- Add ce3 module and iolocal instances
| lazy val ce3 = crossProject(JSPlatform, JVMPlatform) | ||
| .settings(commonSettings) | ||
| .dependsOn(core) | ||
| .settings( | ||
| name := "log4cats-ce3", | ||
| libraryDependencies ++= Seq( | ||
| "org.typelevel" %%% "cats-effect" % catsEffectV | ||
| ) | ||
| ) | ||
|
|
There was a problem hiding this comment.
doesn't core already depend on CE3? oh, it doesn't. cool
There was a problem hiding this comment.
Probably we can move this to the slf4j module to don't create a new module. Speaking from a user experience it'd be handier - one wouldn't need to add a new dependency. WDYT?
There was a problem hiding this comment.
Happy to go with whatever you guys think is most appropriate - just didn't add it to either of the existing ones because:
- Core doesn't depend on CE3
- Isn't strictly speaking an
slf4jconcern
There was a problem hiding this comment.
With #678 we will be depending on cats-effect, and I see no other way to resolve the UUIDGen issue otherwise.
We'll have to track how the dependency on CE in core goes there as well.
There was a problem hiding this comment.
Now it depends on cats-effect-std. This still introduces the IO dependency.
| fk(logger) | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
I somehow missed that LoggerFactory was a thing - nice!
| def withContextF[F[_]: FlatMap]( | ||
| sl: SelfAwareStructuredLogger[F] | ||
| )(ctx: F[Map[String, String]]): SelfAwareStructuredLogger[F] = | ||
| new ModifiedContextFSelfAwareStructuredLogger[F](sl)(existingCtx => ctx.map(_ ++ existingCtx)) |
There was a problem hiding this comment.
I think what we're missing is something like this:
def fa: F[A]
def faWithContext: F[A] = StructuredLogger[F].locally(Map("k" -> "v"))(fa)so that you can wrap an effect, not just a logger. That would help propagate the context to whatever services you're calling, without a need to pass the context or the updated logger.
There was a problem hiding this comment.
Hmm, I guess I was thinking of users doing that using Kleisli.local or similar for IOLocal.
e.g.
def scope[G, T](local: IOLocal[T], value: T)(task: IO[G]): IO[G] =
local.getAndSet(value).bracket(_ => task)(local.set)
There was a problem hiding this comment.
How are you imagining something like StructuredLogger[F].locally would work?
Just specific implementations for where there's a IOLocal or Kleisli around?
There was a problem hiding this comment.
yeah, I think we'll need concrete implementations
There was a problem hiding this comment.
I have come to believe that almost all uses of IOLocal should have that cats.mtl.Local shape. See typelevel/cats-effect#3385. And I like the scope name: that's what Local calls it.
ce3/shared/src/main/scala/org/typelevel/log4cats/ce3/IOLocalHelpers.scala
Outdated
Show resolved
Hide resolved
|
Instead of adding a CE3 module I think we should just add a CE3 dependency to the core module. CE2 is officially sunset and there's already blocking footguns in core that can only be fixed with CE3. |
|
So I had a discussion with @ChristopherDavenport on Discord wrt #677. Although he is supportive of adding a CE dependency to core, he still thinks anything
|
|
So the cats-effect-std dependency landed in core, but |
I've updated the branch with |
rossabaker
left a comment
There was a problem hiding this comment.
I apologize for losing track of this one... I approved the CI run and resolved a merge conflict.
| lazy val ce3 = crossProject(JSPlatform, JVMPlatform) | ||
| .settings(commonSettings) | ||
| .dependsOn(core) | ||
| .settings( | ||
| name := "log4cats-ce3", | ||
| libraryDependencies ++= Seq( | ||
| "org.typelevel" %%% "cats-effect" % catsEffectV | ||
| ) | ||
| ) | ||
|
|
There was a problem hiding this comment.
Now it depends on cats-effect-std. This still introduces the IO dependency.
| .settings(commonSettings) | ||
| .dependsOn(core) | ||
| .settings( | ||
| name := "log4cats-ce3", |
There was a problem hiding this comment.
I would call this log4cats-cats-effect. Anything beyond 3 will be a breaking change, and I'd avoid colloquial abbrevations in a jar name.
| def withContextF[F[_]: FlatMap]( | ||
| sl: SelfAwareStructuredLogger[F] | ||
| )(ctx: F[Map[String, String]]): SelfAwareStructuredLogger[F] = | ||
| new ModifiedContextFSelfAwareStructuredLogger[F](sl)(existingCtx => ctx.map(_ ++ existingCtx)) |
There was a problem hiding this comment.
I have come to believe that almost all uses of IOLocal should have that cats.mtl.Local shape. See typelevel/cats-effect#3385. And I like the scope name: that's what Local calls it.
Should this PR then be in terms of |
|
I would have thought so, until cats-mtl's future stability was questioned on this pull request. The uncertainty around that statement is blocking a cats-effect PR, a clear path forward on otel4s, and now this. |
|
Yeah. I know it's annoying, but might be worth pausing on this one as well until that's decided. We already have a CE dependency in log4cats core, and CE is already (technically) tied to MTL versioning, and thus so are we. |
|
If @wunderk1nd-e isn't desperate for a release on that, I think that's a sound strategy. The fact everything is being done twice is because there's a lovely type class for this if we'd accept it as a routine dependency. |
|
Is it worth it/feasible to add a plain and simple |
|
I am now copy and pasting |
|
CE v3.6.0 was finally released with a dependency on Cats MTL and a |
|
Hey, I'll be looking into this PR and trying to make the final changes. I'll update here as I progress. |
|
Closing in favor of it's continuation in #905 |