Add some helpers for using Kleisli or IOLocal for logging context

[wunderk1nd-e]

• Add helpers for logging with some propagated ctx and kleisli implementation
• Add ce3 module and iolocal instances

[armanbilge]

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.

• https://github.com/typelevel/log4cats/issues/677

[armanbilge]

So I had a discussion with @ChristopherDavenport on Discord wrt https://github.com/typelevel/log4cats/issues/677. Although he is supportive of adding a CE dependency to core, he still thinks anything IOLocal-based should be in a separate module.

I would expect that should be in a different module. Not core Because it's not a way I think folks expect, and the way to do it would be unsafe almost certainly. Since they will globalize. IOLocal is overspecified. And FiberLocal is a side library. So it should be a module or repo with FiberLocal which is a better abstraction then forcing everything to IO

[rossabaker]

So the cats-effect-std dependency landed in core, but IOLocal would require the full cats-effect. Doing that would pull cats-effect (and IO) into all the downstream projects that limited themselves to cats-effect-std. That's a pretty good argument for a separate module.

[wunderk1nd-e]

So the cats-effect-std dependency landed in core, but IOLocal would require the full cats-effect. Doing that would pull cats-effect (and IO) into all the downstream projects that limited themselves to cats-effect-std. That's a pretty good argument for a separate module.

I've updated the branch with main - any chance you could approve the workflow run? 🙏

[armanbilge]

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 Local, instead of offering specific instances?

[rossabaker]

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.

[armanbilge]

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.

[rossabaker]

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.

[mattyjbrown]

Is it worth it/feasible to add a plain and simple LoggerFactory.withContext, as a way of propagating context when you're passing around LoggerFactorys, or is that going to conflict the eventual implementation of this PR?