-
Notifications
You must be signed in to change notification settings - Fork 74
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 some helpers for using Kleisli or IOLocal for logging context #676
base: main
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doesn't core already depend on CE3? oh, it doesn't. cool
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
slf4j
concern
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now it depends on cats-effect-std
. This still introduces the IO
dependency.
@@ -48,4 +48,20 @@ object LoggerFactory extends LoggerFactoryGenCompanion { | |||
fk(logger) | |||
} | |||
} | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I think we'll need concrete implementations
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |