Hi :slightly_smiling_face: I’m curious about the A...

# kotlintest

[wasyl]

Hi 🙂 I’m curious about the Arrow dependency that’s pulled in with KotlinTest — did you have a discussion somewhere about it being not part of the public API? For example having Arrow matchers in a separate artifact, and if KotlinTest uses Arrow internally then not exposing it?
I’m not using Arrow but with KotlinTest I get tons of extension functions from it on most of the classes. Should I just e.g. exclude Arrow transitive dependency if I’m not gonna use those matchers?
I only recall there was some discussion about splitting core and matchers into multiple artifacts but afaik the result was that there will be only one artifact. Maybe it’s something that could be reconsidered for the next major version?

[LeoColman]

I believe that arrow is an implementation dependency only, isn't it?

[LeoColman]

So it doesn't get shipped along with KT itself

[wasyl]

🤔 perhaps I have misconfigured something

[LeoColman]

I think that's what expected. If arrow is getting shipped (and not only used) with KT, that's likely a mistake

[wasyl]

There’s api "io.arrow-kt:arrow-core:$arrow_version" in kotest-assertions/build.gradle

[wasyl]

Here’s testCompileClasspath from my project, I omitted non-kotlintest dependencies:

[wasyl]

+--- io.kotlintest:kotlintest-runner-junit5 -> 3.4.2
|    +--- io.kotlintest:kotlintest-core:3.4.2
|    |    \--- io.kotlintest:kotlintest-assertions:3.4.2
|    |         +--- io.arrow-kt:arrow-core-data:0.9.0
|    |         |    \--- io.arrow-kt:arrow-annotations:0.9.0

[LeoColman]

That api should probably be an implementation, I suppose?

[LeoColman]

What might have happened?

[wasyl]

Wouldn’t it be an issue when you actually have public api that use Arrow classes?

[LeoColman]

I don't think so

[LeoColman]

There was a big discussion at #feed earlier this year about exactly this

[wasyl]

Yep, I now see the same for ktor assertions

[LeoColman]

How implementation let's your project work but api brings those classes to the user

[LeoColman]

Yep, I now see the same for ktor assertions

The same as in api or implementation?

[wasyl]

Sorry, I meant ktor-assertions has implementation dependency on ktor

[wasyl]

So such dependency is fine

[LeoColman]

So we probably could change this

[wasyl]

Does KotlinTest use Arrow classes internally?

[LeoColman]

Yes

[wasyl]

And in the assertions project too?

[LeoColman]

I think we do for somethings, although I'm not sure

[wasyl]

I don’t see any arrow string in kotest-assertions/src directory

[wasyl]

Perhaps Arrow can be removed from that module completely?

[wasyl]

I’m looking for Arrow usage outside arrow-assertions module, and tbh I see little reason to even use it at all. Most of the APIs used are Try, Success and Failure, and this is quite trivial to implement manually, and a big dependency could be removed as a result

[wasyl]

Seems like most of it could even be covered by Kotlin’s Result class

[LeoColman]

@sam What do you think about this? Perhaps we don't need to include Arrow in KT?

[sam]

I think we would continue to use arrow more and more in the implementation. I’m a big fan. But shouldn’t implementation be hiding this anyway ?

[LeoColman]

I think it's not implementation and that's why it's being shipped

[sam]

Ok lets change it

[sam]

Although I've has issues with implementation if it's exposed

[sam]

Eg in hoplite

[sam]

But I don't think we expose any arrow classes

[LeoColman]

As in we return something from arrow, right? I think the only parts in which we expose it is inside arrow module itself

[sam]

Yeah it's only used internally

[sam]

Lets switch it to implementation