Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 13:02
    scala-steward closed #1404
  • 13:02
    scala-steward commented #1404
  • 13:02
    scala-steward review_requested #1407
  • 13:02
    scala-steward review_requested #1407
  • 13:02
    scala-steward opened #1407
  • Mar 03 21:33
    neko-kai closed #1400
  • Mar 03 21:32
    neko-kai review_requested #1406
  • Mar 03 21:32
    neko-kai opened #1406
  • Mar 03 13:49
    neko-kai closed #1403
  • Mar 03 13:32
    neko-kai closed #1405
  • Mar 01 05:02
    scala-steward review_requested #1405
  • Mar 01 05:02
    scala-steward review_requested #1405
  • Mar 01 05:02
    scala-steward opened #1405
  • Feb 23 03:04
    scala-steward review_requested #1404
  • Feb 23 03:04
    scala-steward review_requested #1404
  • Feb 23 03:04
    scala-steward opened #1404
  • Feb 23 01:02
    scala-steward review_requested #1403
  • Feb 23 01:02
    scala-steward review_requested #1403
  • Feb 23 01:02
    scala-steward opened #1403
  • Feb 19 15:04
    neko-kai closed #1402
Kai
@neko-kai
There’s currently an effort in zio to provide enough features to run distage-testkit on top of it, so we may at some point provide an implementation on top of ZIO Test’s runner that wouldn’t suffer the issue. Scalatest is nearly abandoned and extremely unresponsive to issues and PRs so we didn’t try to patch the issue upstream, also since we’re using Intellij for development fixing this wasn’t a very high priority yet
Didac
@umbreak
We are also using Intellij. So it isn’t a problem for us to run the tests through the IDE. Thanks
Paul S.
@pshirshov
We have some plans on implementing our own testkit (or integrating with zio test). Unfortunately scalatest is too limited to properly support our workflow with global planning. Though at the moment we have no ETA, it's not an easy task
Bogdan Roman
@bogdanromanx
thanks @neko-kai and @pshirshov for the explanations on how to properly use the container support in distage; it’s really useful!
to comment on the need for accessing on the locator directly:
  • we need to be able to configure the injection plan based on arguments that are passed to the CLI
  • unfortunately, due to the way that decline works, we’re only able to produce a configuration object only after evaluating all the subcommands and arguments / flags; a simple example would be the following: imagine some part of the code relies on having a Transactor[F] instance, but if you have something like —dbhost 127.0.0.1 as a possible argument, you can only assemble the configuration and bindings only after the evaluation of the command
  • this makes stuff a bit awkward since it would be a lot of code repetition for shared arguments if you’d like to benefit from the instance construction from distage; having access to the locator as a resource is quite cool, since you can decide what to execute and still benefit from the distage’s wiring
on a separate note: what is your experience in using bifunctors over monofunctors in real applications; we’ve mostly used EitherT but it’s not really ergonomic
Bogdan Roman
@bogdanromanx
we do prefer defering the decision on choosing an effect type, so most of our codebase is using tagless; since typeclasses for F[+_,+_] are not defined in something like cats-effect, it’s either monofunctor with cats typeclasses or zio without abstracting over the effect
Adriani Furtado
@Adriani277
@bogdanromanx have looked into BIO as a means to use tagless with a bi-functor?
You can covert your codebase to bi-functor tagless with BIO and use the interop whenever you need cats instances
Paul S.
@pshirshov

on a separate note: what is your experience in using bifunctors over monofunctors in real applications; we’ve mostly used EitherT but it’s not really ergonomic

It's awesome, use it, you won't regret

Didac
@umbreak
Yes we are aware of BIO. However we haven’t used it yet. As @bogdanromanx said, we try to abstract on an effect type 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
Bogdan Roman
@bogdanromanx
thanks for your thoughts!
Adriani Furtado
@Adriani277
@umbreak I have recently gone through the change you guys are attempting. We where between BIO tagless, Cats EitherT or just committing to ZIO, we decided on BIO since we all really like tagless
Kai
@neko-kai

@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

Also as the project is right now, I think Roles would actually cover its needs quite well, currently I found that the wiring is actually the same for all subcommands and the only difference is in command-line arguments, which roles cover too, you can check the examples here - https://github.com/7mind/distage-example/blob/develop/src/main/scala/leaderboard/LeaderboardRole.scala#L89
Bogdan Roman
@bogdanromanx
@neko-kai many thanks for the pointers and the PR, it’s really useful! ;)
Stan Sobolev
@Jacke

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
@neko-kai
@Jacke If R[_] is a different type that isn't F[Throwable, ?], you could do it like this:
def t[F[+_, +_]: BIOAsync: BIOFork, R[_]: Effect, B](t: R[B]): F[Throwable, B] = {
  import Izumi.functional.bio.catz._
  Concurrent[F[Throwable, ?]].liftIO(Effect[R].toIO(t))
}
Stan Sobolev
@Jacke
yes, perfect
thanks
Kai
@neko-kai
:+1:
Stan Sobolev
@Jacke

@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?

Kai
@neko-kai
@Jacke Does it work if you specify the types explicitly? e.g. t[zio.IO, cats.effect.IO](cats.effect.IO(1))
If you’re on 2.12 you might also be missing compiler options, you need these sbt settings for BIO to work on 2.12:
scalacOptions += "-Ypartial-unification"
scalacOptions += "-Xsource:2.13”
Stan Sobolev
@Jacke

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 :]

Kai
@neko-kai
t[zio.IO, cats.effect.IO, Int](cats.effect.IO(1))
Stan Sobolev
@Jacke

Cool

@ t[zio.IO, cats.effect.IO, Int](cats.effect.IO(1))
res30: zio.package.IO[Throwable, Int] = zio.ZIO$EffectPartial@3c6e3104

Oh, language things :)

Kai
@neko-kai
@umbreak @bogdanromanx There’s just been a new release with pretty significant QoL improvements for both 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
Bogdan Roman
@bogdanromanx
fantastic, thanks @neko-kai
Stan Sobolev
@Jacke

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?

Kai
@neko-kai

@Jacke Yes, but you will need to move all other components to cats.effect.IO too. To change the effect type

  1. 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]

  2. 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]

  3. 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.

Stan Sobolev
@Jacke
Got it, thank you very much
Stan Sobolev
@Jacke

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?

Corey O'Connor
@coreyoconnor
@Jacke one option:
import com.typesafe.config.ConfigFactory
import izumi.distage.config.AppConfigModule

val myModules = AppConfigModule(ConfigFactory.defaultApplication) ++ ...
Stan Sobolev
@Jacke
Does it works only with ZIO? I got multiple errors with cats (I set every type paremeter of my modules to [cats.effect.IO]):
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`
Stan Sobolev
@Jacke

Ops, I solved it by produceF

Injector().produceF[IO](myModules, Roots.Everything).unsafeGet().map(_.get[Module[IO]]).unsafeRunSync

works well, thanks

vonchav
@voonchav_gitlab
Hi @neko-kai , any plan to upgrade LogStage to ZIO RC21? :)
Kai
@neko-kai
@voonchav_gitlab Not sure, due to upstream regressions: zio/zio#3851 Did you check if there’s a binary compatiblity error with logstage & RC21? It may just work with the update if the binary breakage didn’t touch the methods used in logstage.
vonchav
@voonchav_gitlab
@neko-kai I haven't tried upgrading to zio rc21 cuz I'm waiting for other libs to upgrade. But I can definitely try upgrading to rc21 with current version of logstage. Thanks!
vonchav
@voonchav_gitlab
@neko-kai Looks like that issue has been fixed and a rc21-1 is on the way :)
Kai
@neko-kai
@voonchav_gitlab Yup, will release an update soon
vonchav
@voonchav_gitlab
Awesome, thanks!
Kai
@neko-kai
@voonchav_gitlab just tagged 0.10.16 for zio-rc21-2
vonchav
@voonchav_gitlab
Thank you, sir! :)
Anton Solovyev
@Rosteelton

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

Paul S.
@pshirshov

Is there some way to convert other slf4j logs (from other libraries) to logstage format to work with logback?

You mean a way to make slf4j messages structure? Nope

In case you just wish to forward slf4j messages into logstage queue - use slf4j adaptor

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

You can't magically make slf4j messages structured
You may write logstage messages into logback, but you'll have to write some code. We didn't do that because we don't need that but we would welcome your contribution
@Rosteelton