Scala3 version depends on 2.13 artifacts

[Tomas Herman]

Hi,

it seems that mdoc_3 depends on org.scalameta : mdoc-cli_2.13. This is causing builds to fail because:

[error] Modules were resolved with conflicting cross-version suffixes in ProjectRef(uri("file:/Users/tomas.herman/workspace/datadog4s/"), "site"):
[error]    org.scala-lang.modules:scala-collection-compat _3, _2.13

Am i doing something wrong or is this an error on mdoc side? This error only shows up for sbt 1.5.5, for 1.5.4 it works well, but im not sure it's correct.

Thanks

[Ólafur Páll Geirsson]

Thank you for reporting! This is working as expected. The mdoc-cli module does not compile against Scala 3. You should be able to pick one of scala-collection-compat_{3,2.13}, I think they are the same. Even if we removed the scala-collection-compat module and managed to compiler mdoc-cli against Scala 3, it will continue to have a dependency on the scalameta_2.13 dependency (which uses macro annotations making it very difficult to compile against Scala 3).

[Tomas Herman]

thanks, solved this on my own in avast/datadog4s#422

[Tomas Mikula]

Hi, so what is the general solution if mdoc depends on artifact_2.13 and the project that I am documenting with mdoc depends on artifact_3?

I just encountered this problem with com.lihaoyi:sourcecode (mdoc depending on sourcecode_2.13, my project on sourcecode_3).

I was able to adapt @tomasherman's solution (see my solution below), but I feel that I am just lucky that the way I use mdoc does not need sourcecode_2.13 at runtime.

lazy val docs = project
  .in(file("docs-project"))
  .dependsOn(core)
  .enablePlugins(MdocPlugin)
  .settings(
    // mdoc (transitively) depends on sourcecode_2.13,
    // which conflicts with core's dependency on sourcecode_3
    libraryDependencies := libraryDependencies.value.map(_ excludeAll (
      ExclusionRule(organization = "com.lihaoyi", name = "sourcecode_2.13"),
    )),
 )

[Anton Sviridov]

Yeah, it's problematic, but your solution is the only one I can think of now.

While I'm going to update metaconfig to scala-3 only version in #563, I can see it's not the only source of 2.13:

tree brought by metaconfig, solvable

   ├─ org.scalameta:mdoc-cli_2.13:2.2.23
   │  ├─ com.geirsson:metaconfig-typesafe-config_2.13:0.9.10
   │  │  ├─ com.geirsson:metaconfig-core_2.13:0.9.10
   │  │  │  ├─ com.lihaoyi:pprint_2.13:0.5.9
   │  │  │  │  ├─ com.lihaoyi:fansi_2.13:0.2.9
   │  │  │  │  │  └─ com.lihaoyi:sourcecode_2.13:0.2.1 -> 0.2.7
   │  │  │  │  └─ com.lihaoyi:sourcecode_2.13:0.2.1 -> 0.2.7
   │  │  │  ├─ org.scala-lang:scala-library:2.13.1 -> 2.13.6
   │  │  │  ├─ org.scala-lang.modules:scala-collection-compat_2.13:2.1.2 -> 2.4.4 (possible incompatibility)
   │  │  │  │  └─ org.scala-lang:scala-library:2.13.5 -> 2.13.6
   │  │  │  └─ org.typelevel:paiges-core_2.13:0.3.0
   │  │  │     └─ org.scala-lang:scala-library:2.13.0 -> 2.13.6
   │  │  └─ org.scala-lang:scala-library:2.13.1 -> 2.13.6

tree brought by scalameta

   │  └─ org.scalameta:scalameta_2.13:4.4.27
   │     ├─ org.scala-lang:scala-library:2.13.6
   │     ├─ org.scala-lang:scalap:2.13.6
   │     │  └─ org.scala-lang:scala-compiler:2.13.6
   │     │     ├─ org.scala-lang:scala-library:2.13.6
   │     │     └─ org.scala-lang:scala-reflect:2.13.6
   │     │        └─ org.scala-lang:scala-library:2.13.6
   │     └─ org.scalameta:parsers_2.13:4.4.27
   │        ├─ org.scala-lang:scala-library:2.13.6
   │        └─ org.scalameta:trees_2.13:4.4.27
   │           ├─ org.scala-lang:scala-library:2.13.6
   │           ├─ org.scalameta:common_2.13:4.4.27
   │           │  ├─ com.lihaoyi:sourcecode_2.13:0.2.7
   │           │  ├─ com.thesamet.scalapb:scalapb-runtime_2.13:0.11.4
   │           │  │  ├─ com.thesamet.scalapb:lenses_2.13:0.11.4
   │           │  │  │  ├─ org.scala-lang:scala-library:2.13.6
   │           │  │  │  └─ org.scala-lang.modules:scala-collection-compat_2.13:2.4.4
   │           │  │  │     └─ org.scala-lang:scala-library:2.13.5 -> 2.13.6
   │           │  │  ├─ org.scala-lang:scala-library:2.13.6
   │           │  │  └─ org.scala-lang.modules:scala-collection-compat_2.13:2.4.4
   │           │  │     └─ org.scala-lang:scala-library:2.13.5 -> 2.13.6
   │           │  └─ org.scala-lang:scala-library:2.13.6
   │           └─ org.scalameta:fastparse-v2_2.13:2.3.1
   │              ├─ com.lihaoyi:geny_2.13:0.6.5
   │              └─ com.lihaoyi:sourcecode_2.13:0.2.3 -> 0.2.7
   │  │  │  └─ org.scala-lang:scala-library:2.13.6
   │  │  │     └─ org.scala-lang:scala-library:2.13.6
   │  │  └─ org.scala-lang:scala-library:2.13.6

The latter is harder to solve because of macro annotations in scalameta. And apparently fastparse, which I didn't think about before.

Unfortunately it is possible to end up in a situation where this 3/2.13 sandwich breaks. It shouldn't be very likely, unless you're doing a lot of work within the com-lihaoyi libraries..

[Tomas Mikula]

Thanks for commenting. I guess I should be fine.

Are you suggesting that meta-programming in Scala 3 is not as powerful as macro annotations?

[Anton Sviridov]

The macro annotations' abilityb to synthesize members is the thing that Scala 3 doesn't support: https://contributors.scala-lang.org/t/annotation-macros/1211

I can't really speak to the exact comparison in terms of power between whitebox/blackbox macros in Scala 2 and Scala 3 metaprogramming facilities, but macro annotations are a particular problem.