sbt testOnly
doesn’t work correctly with distage-testkit – in reality all tests are run, not just the ones reported. Try running InfluxSpec
class test from IntelliJ IDEA - it will work correctly. You can also run select test cases with testOnly — -z “<test-name-patter>”
, but this will work for running specific test classes, not specific test suites
run
method is called, collect tests that are registered – this enables global sharing and all the features stemming from having a single entrypoint. Under sbt
this doesn’t work because scalatest’s sbt runner launches tests one-by-one and does not pass any parameters to figure out the enabled suites, the only way to figure out which suites were selected would be to wait until there was a big enough pause between run
calls, which would be pretty horrifying - so it instead it just launches everything
F[_]
but in fact a lot of times we end up using F[Either[_, _]]
on our signatures in order to catch errors not thrown on the F. And obviously is a pain to work with them directly. Probably using something like BIO would be better
@bogdanromanx
I see what you mean by decline
requiring executing the actions immediately inside the parser which makes it harder to decouple subcommands from wiring.
Well, one thing you could do to combat that is to not return F[ExitCode]
directly from the parser, but to parse into an ADT that describes the subcommand and the command-line arguments – that way you can do the wiring in one place where you pattern match on that ADT instead of in many places around the code.
Another option would be to not spread the command-line parsers across multiple classes, but put them all into Cli[F]
- this would again allow to centralize wiring and remove the LocatorRef parameter.
I’ve looked at your project and implemented one way to get rid of recursion on LocatorRef that isn’t one of the suggestions above, but I think is minimally disruptive to the way it’s organized right now - I’ve opened a PR at BlueBrain/nexus#1176
Hey guys, I new in BIO and I need assistance.
I have
def t[F[+_,+_]: BIOPrimitives: BIO : BIOApplicative, R[_] : Sync : MonadError[?[_], Throwable], B](t: R[B]): F[Throwable, Int] = ??? // How to get F[_,_] from R (which is cats effect IO instance)
to be able to do something like this
t(IO(1/0))
// zio.IO[Throwable, Int]
@Kai I getting:
@ t(IO(1))
cmd30.sc:1: type mismatch;
found : izumi.functional.bio.PredefinedHelper.Predefined.Of[izumi.functional.bio.BIOAsync3[zio.ZIO]]
(which expands to) izumi.functional.bio.BIOAsync3[zio.ZIO]{type IsPredefined = izumi.functional.bio.PredefinedHelper.Predefined}
required: izumi.functional.bio.BIOAsync[[+E, +A]zio.ZIO[R,E,A]]
(which expands to) izumi.functional.bio.BIOAsync3[[-R, +E, +A]zio.ZIO[R,E,A]]
val res30 = t(IO(1))
Is there any workaround?
scalacOptions += "-Ypartial-unification"
scalacOptions += "-Xsource:2.13”
No, it's not
@ t[zio.IO, cats.effect.IO](cats.effect.IO(1))
cmd30.sc:1: wrong number of type parameters for method t: [F[+_, +_], R[_], B](t: R[B])(implicit evidence$1: izumi.functional.bio.BIOAsync[F], implicit evidence$2: izumi.functional.bio.BIOFork[F], implicit evidence$3: izumi.functional.bio.BIO[F], implicit evidence$4: cats.effect.Effect[R], implicit cs: cats.effect.ContextShift[R])F[Throwable,B]
val res30 = t[zio.IO, cats.effect.IO](cats.effect.IO(1))
^
Compilation Failed
I'm on 2.13.2 and it still very strange :]
distage-testkit
& distage-framework-docker
- https://github.com/7mind/izumi/releases/tag/v0.10.9 - should make memoization behavior far better & more consistent within your project (and make it obvious through logs). Note: you can now turn off all logging incl. config loading in testkit by setting TestConfig#logLevel
Hey guys, I have another problem, I'm trying to use cats.IO resource in MainPlugin,
but I getting this error
Suppressed: izumi.distage.model.exceptions.IncompatibleEffectTypesException: Incompatible effect types: Can't execute effect in `λ %0 → cats.effect.IO[+0]` which is neither Identity, nor a subtype of the effect that Provisioner was launched in: `λ %1 → zio.ZIO[-Any,+Throwable,+1]`
Clarification:
- To execute `.fromEffect` and `.fromResource` bindings for effects other than `Identity` you need to use `Injector.produceF` method with F type corresponding to the type of effects/resources you inject
- Subtype type constructors are allowed. e.g. when using ZIO you can execute actions with type IO[Nothing, ?] when running in IO[Throwable, ?]
at izumi.distage.provisioning.PlanInterpreterDefaultRuntimeImpl.$anonfun$verifyEffectType$1(PlanInterpreterDefaultRuntimeImpl.scala:215)
at izumi.distage.model.effect.DIEffect.$anonfun$traverse_$2(DIEffect.scala:44)
at zio.internal.FiberContext.evaluateNow(FiberContext.scala:844)
... 19 more
Caused by: zio.Cause$FiberTrace: Fiber failed.
That's because
make[Transactor[F[Throwable, ?]]].fromResource[TransactorResource[F[Throwable, ?]]]
I can make this with zio.IO, but if I do
//make[Transactor[R]].fromResource[TransactorResourceCats[R]]
where R == cats.IO
I got the error from above.
Is it possible to get cats.IO Resource effect with IO{], rather then with F[,_]: TagKK : BIO?
@Jacke Yes, but you will need to move all other components to cats.effect.IO too. To change the effect type
in app: change the RoleAppLauncher's effect in https://github.com/7mind/distage-example/blob/develop/src/main/scala/leaderboard/LeaderboardRole.scala#L121 - inherit from RoleAppLauncher.LauncherF[cats.effect.IO]
instead of LauncherBIO[zio.IO]
in tests change the testkit's effect in https://github.com/7mind/distage-example/blob/develop/src/test/scala/leaderboard/tests.scala#L14 - inherit from DistageSpecScalatest[cats.effect.IO]
instead of DistageBIOEnvSpecScalatest[zio.IO]
When using Injector directly, not via distage-framework or distage-testkit, the effect type is determined by the type parameter passed to Injector#produceF
/#produceRunF
/#produceGetF
etc
You will need to move all components to the new effect type, only one effect type can be used at a time.
Hi guys, i'm trying to use injector directly via:
val myModules = CatsAppPlugin.modules.app[IO] ++
CatsAppPlugin.modules.repoProd[IO] ++
CatsModule ++
CatsAppPlugin.modules.configs ++
CatsAppPlugin.modules.api[IO] ++
CatsAppPlugin.modules.repoDummy[IO]
val plan = Injector().plan(myModules, Roots.Everything)
var ctx: Module[IO] = Injector().produce(myModules, Roots.Everything).unsafeGet().get[Module[IO]]
but I got an error
com.spread0x.http4s.service.UserServiceSpec *** ABORTED ***
izumi.distage.model.exceptions.ProvisioningException: Provisioner stopped after 1 instances, 5/64 operations failed:
- {type.izumi.distage.config.model.AppConfig} (CatsAppPlugin.scala:162), MissingInstanceException: Instance is not available in the object graph: {type.izumi.distage.config.model.AppConfig}.
Required by refs:
* {type.com.spread0x.config.PostgresCfg}
* {type.com.spread0x.config.PostgresPortCfg}
* {type.com.spread0x.config.ServerConfig}
How can I inject izumi.distage.config.model.AppConfig to fix the error?
com.spread0x.http4s.http.UserRoutesSpec *** ABORTED ***
izumi.distage.model.exceptions.ProvisioningException: Provisioner stopped after 1 instances, 4/65 operations failed:
- {type.org.http4s.client.Client[=λ %0 → IO[+0]]} (CatsAppPlugin.scala:86), IncompatibleEffectTypesException: Incompatible effect types: Can't execute effect in `λ %0 → cats.effect.IO[+0]` which is neither Identity, nor a subtype of the effect that Provisioner was launched in: `λ %0 → 0`
Hi all! I would like to ask about logstage with logback configuration.
Now I have json log in %msg
field with this setting: LogSinkLegacySlf4jImpl(LogstageCirceRenderingPolicy())
.
Is there some way to convert other slf4j logs (from other libraries) to logstage format to work with logback?
Or maybe you can tell me another way to use logstage api for json rendering with logback template
Or maybe you can tell me another way to use logstage api for json rendering with logback template
I'm not sure what exactly you want to do. We have logstage-sink-slf4j
which dumps logstage messages into slf4j. You may use it as a reference and implement your own logstage -> logback adapter
We also have logstage-adapter-slf4j
which works as an slf4j backend and forwards sl4j->logstage