Migrate classes to new package structure#748
Conversation
modules/tail-sampling/src/main/scala/trace4cats/samplling/tail/RateTailSpanSampler.scala
Outdated
Show resolved
Hide resolved
modules/meta/src/test/scala/io/janstenpickle/trace4cats/meta/TracedSpanExporterSpec.scala
Show resolved
Hide resolved
|
@janstenpickle do you need help with this PR? |
Sorry, I've been really busy the last couple of week. Yes please feel free to commit to this branch if you have some time! |
|
Hopefully I've got everything now 😅 |
|
@bplommer how does this new structure look to you? |
|
Will review tonight |
modules/context-utils-laws/src/main/scala/trace4cats/context/laws/discipline/AskTests.scala
Show resolved
Hide resolved
| package object trace4cats { | ||
| type SpanName = String | ||
| type SpanParams = (SpanName, SpanKind, TraceHeaders, ErrorHandler) | ||
| type ResourceKleisli[F[_], -In, +Out] = Kleisli[Resource[F, +*], In, Out @uncheckedVariance] |
There was a problem hiding this comment.
I was going to suggest renaming ResourceKleisli to something that reflects purpose rather than implementation, and possibly changing it from a type alias to part of a class heirarchy with EntryPoint. But again, not something that should happen in this PR - just mentioning it while I remember
There was a problem hiding this comment.
The main reason for not making this its own class is that we get a lot of things for free with Kleisli and its input and output aren't fixed to the input/output of the entry point. This allows us to compose the entrypoint with other means of establishing some context from some input. There's an example of this in the http4s library.
|
Looks good! I wonder if types from |
Yes, that might be handy for things like the IDs and context, I'll take a look. |
|
@bplommer @catostrophe how does this look to you both now, shall I merge? I've got a scalafix branch in progress at the moment as well, so once the other repos are done we should be getting close to a release |
|
Sorry for being so slow, been busy at $WORK. Checking now... |
No problem, I know the feeling! |
| package io.janstenpickle.trace4cats.base.context | ||
| package laws | ||
| package discipline | ||
| package trace4catstests.context.laws.discipline |
| import cats.~> | ||
| import org.scalacheck.Cogen | ||
| import trace4cats.context.Unlift | ||
| import trace4catstests.context.laws.discipline.UnliftTests |
| import trace4cats.context.iolocal.GenIO | ||
| import trace4cats.context.iolocal.instances.ioLocalProvide | ||
| import trace4cats.context.laws.BaseSuite | ||
| import trace4catstests.context.laws.discipline.ProvideTests |
@catostrophe - It was suggested by @bplommer. Sorry, I resolved the comment so you wouldn't have seen it! |
I still haven't got the idea behind it. I've never seen such a separation before in the context of See: |
|
These "tests" are actually rule sets that you use in real tests to check some concrete implementation for satisfying them. |
I've got to admit I took the recommendation at face value. I wonder if you were thinking more of the separate test modules rather than discipline tests @bplommer? |
Yes, afraid I didn't look very closely before suggesting that. Anything that's going to be published as an artifact, I'd leave in the |
|
Could we revert the introduction of The rest is fine 👍 |
Cool, I'll revert this now then merge. Thanks all! |
Addresses #744