PgSvcExample may be a resource, in that case it would be created before all the tests and finalized after all the tests
We need more customized integration checks than what’s provided by the ResourceCheck trait: https://github.com/7mind/distage-livecode/blob/livecode/src/main/scala/livecode/code.scala#L186
We have something as follows: https://github.com/BlueBrain/nexus/blob/master/cli/src/test/scala/ch/epfl/bluebrain/nexus/cli/postgres/AbstractPostgresSpec.scala#L45
@umbreak The above suggestion is correct, the way to do this currently is to create a
DIResource with acquire/release actions that are your before/afterAll actions. Then you can pin the resource to be global via memoizationRoots AND pin the resource to be a dependency of all tests such that it doesn’t need to be summoned manually as a parameter for its acquire/release actions to execute.final class MyTransactor[F[_]] extends DIResourceBase[F, MyTransactor[F]] {
def acquire = waitForPostgres
def release = deleteAllTables
}
trait MyTest extends DistageAbstractScalatestSpec[IO] {
override def config = super.config.copy(
memoizationRoots = super.config.memoizationRoots ++ Set(
DIKey.get[MyTransactor[F]], // force MyTransactor to be acquired/released only once per test-run
),
forcedRoots = super.config.forcedRoots ++ Set(
DIKey.get[MyTransactor[F]], // force MyTransactor to be acquired/released always, no matter if the running tests declare it as a parameter
)
)
}
That would help, yes. Also as you can see in the example I’m building a Resource for a Transactor (
make[Transactor[IO]].fromEffect(...)) and for the waiting logic I need the transactor itselfprivate def waitForPostgresReady(xa: Transactor[IO], maxDelay: FiniteDuration = 30.seconds): IO[Unit] = ???
Yep, that may be kind of a problem
That’s why I ended up doing it like in the here: https://github.com/BlueBrain/nexus/blob/master/cli/src/test/scala/ch/epfl/bluebrain/nexus/cli/postgres/AbstractPostgresSpec.scala#L45
@umbreak : could you describe your usecase as precise as possible please?
I mean what behaviour you wish to have?
I’ll detail it soon, I have to answer a call first. Thanks again
reuse=true allows reusing the same container between multiple test runs on top of that
It is used to compute the locator inside a subcommand:
See: https://github.com/BlueBrain/nexus/blob/master/cli/src/main/scala/ch/epfl/bluebrain/nexus/cli/AbstractCommand.scala#L23
And: https://github.com/BlueBrain/nexus/blob/master/cli/src/main/scala/ch/epfl/bluebrain/nexus/cli/modules/influx/Influx.scala#L25
See: https://github.com/BlueBrain/nexus/blob/master/cli/src/main/scala/ch/epfl/bluebrain/nexus/cli/AbstractCommand.scala#L23
And: https://github.com/BlueBrain/nexus/blob/master/cli/src/main/scala/ch/epfl/bluebrain/nexus/cli/modules/influx/Influx.scala#L25
We implemented it as a last-resort feature, it is not expected to be needed under normal circumstances
1 reply
This will (optionally) rebuild the entire application, right? distage has a mechanism ‘roles’ for the use-case of building parts of the application for sub-commands - https://izumi.7mind.io/latest/release/doc/distage/distage-framework.html#roles
It’s possible they could be used to avoid the recursive design here, probably. e.g. you could pass parameters to influx cli subcommand like
It’s possible they could be used to avoid the recursive design here, probably. e.g. you could pass parameters to influx cli subcommand like
./app :influx param1 —param2
@neko-kai If I had something like you posted:
trait AbstractTest extends DistageAbstractScalatestSpec[IO] {
override def config = super.config.copy(
memoizationRoots = super.config.memoizationRoots ++ Set(
DIKey.get[Transactor[F]], DIKey.get[InfluxClient[F]]
)
)
}And then I have 2 tests: PostgresSpec extends AbstractTest and InfluxSpec extends AbstractTest and I run testOnly *InfluxSpec I can see how the Postgres container is also started and the waitForPostgresReady is also running, even though I’m just running the InfluxSpec.
@umbreak Actually the problem here is that
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
The problem here is that scalatest’s sbt runner does not pass information down to suites as to what suites it’s trying to launch – and distage-testkit relies on launching just once and does the rest of test discovery on its own. For intellij’s / scalatest’s own ScalaTestRunner, distage does not do discovery because they have a specific protocol - all test classes are constructed first and tests launch after everything is constructed – this allows distage-testkit to register during construction and once its’
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
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
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:
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
You can covert your codebase to bi-functor tagless with BIO and use the interop whenever you need cats instances
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
@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
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]