Can I use Kotest Arrow assertions while working on...

# arrow

[Lukasz Kalnik]

Can I use Kotest Arrow assertions while working on Arrow itself?
I'm working on a PR for the arrow-core-retrofit module. I added a dependency on io.kotest.extensions:kotest-assertions-arrow but when I try to use the shouldBeRight assertion the test doesn't compile with the error "Cannot access class 'arrow.core.Either'. Check your module classpath for missing or conflicting dependencies"

[simon.vergauwen]

That seems to be a dependency conflict. Like some library is not relying on api("arrow-core") but on implementation("arrow-core") which results in the dependency not being available in the resulting jar.

[simon.vergauwen]

Yes, I think this is the issue.
https://github.com/kotest/kotest-extensions-arrow/blob/master/kotest-assertions-arrow/build.gradle.kts#L154

It’s even worse, compileOnly is even more restrictive compared to implementation. So it’s missing the jar at runtime.


We should put more love in the kotest arrow integrations though. I’d love to move everything we have in the Arrow repo in the test modules to be moved to Kotest Extensions.

cc\\ @Imran/Malic

[simon.vergauwen]

Created a ticket. https://github.com/kotest/kotest-extensions-arrow/issues/130

[Imran/Malic]

We had other issues with putting the Arrow Jar inside kotest. Bc in projects people would have to isolate or exclude those dependencies as it would create dependency conflicts between version, if they happen to use a different Arrow version or have for instance an arrow dependency in their compile classpath.

So far we got good responses just to add implementation("arrow-core") , bc they end up having it in the classpath anyways. Unless api("arrow-core") prevents those dependency conflicts I haven’t tested it

[simon.vergauwen]

Oh, I see…
Makes sense, but why did that error then come up in the tests of retrofit module 🤔

I guess the retrofit module doesn’t declare it’s dependency on Arrow Core correctly then.

[Imran/Malic]

probably.. But I can add it to the docs in kotest 😄 If that helps?

[simon.vergauwen]

Yes, that’d be great!

[Lukasz Kalnik]

The arrow-core-retrofit has a dependency compileOnly(projects.arrowCore).
Would the best solution be to add testImplementation(projects.arrowCore)?
I assume we should not just change compileOnly to implementation as then the implementers could have the same problem with different arrow-core versions in their projects?

[Lukasz Kalnik]

On the other hand it feels kind of weird to have to go through these lengths and every time tell developers "if you use arrow-core-retrofit you need a dependency on arrow-core as well". Is there no better solution in Gradle for this?

[simon.vergauwen]

Right, I think we need to use api(projects.arrowCore) instead of compileOnly(projects.arrowCore).
That should fix the issue I believe, and will instruct Gradle/Maven to download arrow-core as a transitive dependency from arrow-core-retrofit.

It’s a great PR! Thanks a lot @Lukasz Kalnik. This was a much needed improvement. I will try to make some time asap to review properly

[Lukasz Kalnik]

Thanks Simon, I'm happy to contribute! You all in the Arrow community also certainly make it easier by being so helpful and responsive to all questions.

[Lukasz Kalnik]

Here it looks like compileOnly should actually not be used apart from some very rare cases:
https://discuss.gradle.org/t/is-it-recommended-to-use-compileonly-over-implementation-if-another-module-use-implementation-already/26699

[Imran/Malic]

Alignment rules look pretty interesting https://docs.gradle.org/current/userguide/dependency_version_alignment.html, does anyone have experience with it in kmm?

[Lukasz Kalnik]

@simon.vergauwen Back to my original question: I have added to arrow-retrofit-core the following dependencies:

testImplementation(projects.arrowCore)
  testImplementation("io.kotest.extensions:kotest-assertions-arrow:1.2.1")

and the tests pass, the build also passes, but there is still the same error shown in the IDE...

[Lukasz Kalnik]

Cannot access class 'arrow.core.Either'. Check your module classpath for missing or conflicting dependencies

[Lukasz Kalnik]

The same IDE error is shown when I change projects.arrowCore to implementation (instead of compileOnly and testImplementation)

[simon.vergauwen]

@Lukasz Kalnik I think it can become the following. That is also in line with thee article you shared above, and that article is in line with my understanding of Gradle/dependencies.

dependencies {
  api(libs.kotlin.stdlibJDK8)
  api(projects.arrowCore)
  api(libs.squareup.retrofit)
  testCompileOnly(libs.kotlin.reflect)
  testRuntimeOnly(libs.kotest.runnerJUnit5)
  testImplementation(projects.arrowCoreTest)
  testImplementation(libs.squareup.retrofitConverterGson)
  testImplementation(libs.squareup.okhttpMockWebServer)
}

cc\\ @Imran/Malic on KMM is should actually be more strict than on the JVM. That’s probably also the reason you still see the error in IDEA, because IDEA might be detecting “something weird” in terms of the dependency configuration. We should probably do a sweep over all the libraries though.
I removed most compileOnly for KMM already, but since this is a JVM module I might’ve missed it.

For example, here we don’t have to expose Kotlin Std as API since it’s already exposed through arrow-core as api.
So relying on arrow-core as api makes Kotlin Std a transitive api dependency.
But since we expose here JDK8 as api, we should still expose it as api I think since std-common is s subset of std-JDK8.

[Lukasz Kalnik]

@simon.vergauwen Unfortunately this didn't help (even with invalidating IntelliJ cache)

[Lukasz Kalnik]

It's weird that the project actually builds and tests pass, only IntelliJ shows this error in editor

[simon.vergauwen]

If that’s the case it’s almost 100% sure a cache bug in Gradle daemon. Afaik invalidating caches might not work for that.
I’ve been running in these issues more in MPP project, and Gradle MPP plugin but not sure it’s related. I will checkout your branch locally, and take a look if I get the same error.

[Lukasz Kalnik]

Thanks! Note that I haven't committed/pushed this change

[Lukasz Kalnik]

Also it's not really critical - all the tests are correctly set up without the convenience Kotest Arrow extensions.

[simon.vergauwen]

Yes, it’s definitely not blocking but we should remove our custom modules and move everything to the official repo for Kotest/Arrow integration

[simon.vergauwen]

I’ll check out the code to review the PR, so I can also take a look at the IDEA error when reviewing the PR 👍