Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scala3 version depends on 2.13 artifacts #545

Closed
tomasherman opened this issue Aug 17, 2021 · 6 comments
Closed

Scala3 version depends on 2.13 artifacts #545

tomasherman opened this issue Aug 17, 2021 · 6 comments

Comments

@tomasherman
Copy link

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

@olafurpg
Copy link
Member

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).

@tomasherman
Copy link
Author

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

@TomasMikula
Copy link

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"),
    )),
 )

@keynmol
Copy link
Collaborator

keynmol commented Sep 28, 2021

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..

@TomasMikula
Copy link

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?

@keynmol
Copy link
Collaborator

keynmol commented Sep 28, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants