Can't use Scala 3 artifact with Scala 2

[kpodsiad]

Hey, is this possible to use cats-core_3 with Scala 2?

//> using scala "2.13.8"

//> using option "-Ytasty-reader"

//> using lib "org.typelevel:cats-core_3:2.8.0"

import cats.syntax.all._

object Main extends App {

}

fails with
can't find type required by method catsInstancesForIdCompat2_6_1 in object cats.Invariant: compat.targetName; perhaps it is missing from the classpath.

I was able to find source code but I'm still not sure if this should be considered as a bug.

[armanbilge]

I'm inclined to say this is not officially supported.

[armanbilge]

Further reading:
https://gist.github.com/djspiewak/b8f2b4547951442102488964bc351cf9#5-dont-rely-on-withdottycompat

[kpodsiad]

Such a quick response 😲

Yeah, I'm aware that mixing _2.13 and _3 in libraries is evil, but this is not my case. I want to migrate an app from 2.13 to 3 and few modules have to stay on 2.13, from bunch of reasons, while others can be easily bumped to 3. All of them depend on cats and are used by some toplevel modules, which puts me in situation where I have to pick which suffix to use :/

[armanbilge]

Right, it's not about whether it's evil or not. It's more that you can't rely on this technique, because it doesn't really work.

The fundamental issue here is that the Scala 3 build of Cats relies on targetName which is defined only in the Scala 3 standard library.
https://scala-lang.org/api/3.x/scala/annotation/targetName.html

So not really sure what you can do about that.

My best advice is to pin to an older version of Cats that doesn't have this requirement. Or, maybe you can try shimming it in Scala 2.

[kpodsiad]

Artifact for Scala 3 is generated with this annotation taken into account. If yes, isn't it only a matter of support for it in tasty reader? I'm not an expert here, just thinking loudly.

Pinning to 2.6.2 is an option which is worth considering, but I'm interested in maybe you can try shimming it in Scala 2 part, could you elaborate more about it?

[kpodsiad]

@bishabosha do you think tasty reader could help in this case?

EDIT: sorry for pinging, I've been not thinking clearly at that moment and it was unnecessary 😅

[armanbilge]

Artifact for Scala 3 is generated with this annotation taken into account.

I am not sure what you mean. In any case this seems like a question/issue for the dotty team. Perhaps a minimum reproduction would help with that investigation.

---

but I'm interested in maybe you can try shimming it in Scala 2 part, could you elaborate more about it?

Your error message says:

can't find type required by method catsInstancesForIdCompat2_6_1 in object cats.Invariant: compat.targetName; perhaps it is missing from the classpath.

I propose one way to fix that, is to define the missing class yourself, so it is on the classpath :)

[kpodsiad]

@armanbilge I have to ask, are you a single person or are you a facade for a whole bunch of people? The amount of your activity and contributions is just insane :D

Clearly, after one week of migrating stuff I'm not thinking anymore, have to reset mind and I'll try workaround which you proposed. Thank you very much from the bottom of my ❤️

[bishabosha]

so using the -Ydebug-tasty flag it seems that the compat package class is "forced" but then has no symbols inside, its worth escalating this to scala/bug I think. Unless it really is not on the classpath and the symbol for it exists for another reason

[bishabosha]

I investigated a little bit and compat.targetName is actually defined in a separate object cats.compat.compat$package, rather than cats.compat.package and I haven't done the set up to integrate top level definition wrapper objects into the package's scope, I justified this by suggesting users manually select the wrapper object, but this clearly doesn't work for annotations.

[bishabosha]

@armanbilge my recommendation is that cats.compat.targetName not be a top level definition, but put in a traditional package object. It will be much easier to support the targetName annotation in scala 2 than top level definitions.

[armanbilge]

@bishabosha thanks for the investigation. Sure, we can make that change. A PR from you or @kpodsiad would be appreciated!

[TonioGela]

@armanbilge I have to ask, are you a single person or are you a facade for a whole bunch of people? The amount of your activity and contributions is just insane :D

[OFFTOPIC] @kpodsiad I just noticed that you quoted my tweet 😂

[EDIT] I added a pr too following @bishabosha suggestion!

[bishabosha]

if you directly use catsInstancesForIdCompat2_6_1 or it is the result of implicit search then it should still fail because there is not support yet for scala.annotation.targetName - but hopefully the wildcard import still is fine

[TonioGela]

Thank @bishabosha. At least now we have a way to perform what @kpodsiad was asking in the issue. Plus, that annotation renaming is in a private package, so technically, library users shouldn't be able to access it.

/cc @armanbilge

[armanbilge]

if you directly use catsInstancesForIdCompat2_6_1 or it is the result of implicit search

I do not see how that would be possible.

cats/core/src/main/scala/cats/Invariant.scala

Lines 129 to 132 in bf216a4

	@deprecated("Added for bincompat", "2.8.0")
	@cats.compat.targetName("catsInstancesForId")
	private[cats] def catsInstancesForIdCompat2_6_1: Comonad[Id] =
	cats.catsInstancesForId