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

Version conflicts and evictions when combining submodules #273

Closed
Dennis4b opened this issue Apr 2, 2018 · 3 comments
Closed

Version conflicts and evictions when combining submodules #273

Dennis4b opened this issue Apr 2, 2018 · 3 comments

Comments

@Dennis4b
Copy link
Contributor

Dennis4b commented Apr 2, 2018

Hi,

edit: this is quite a roundabout way to describe it, see second message

I am not sure if this is the intended behavior or not, but it has caused me some issues so I'd like to clarify.

Making a testcase takes some time so hopefully the following explanation suffices:

Suppose that in my main app definition (a plain ScalaModule) my ivyDeps depend on org.typelevel cats-core 1.1.0 and on cats-effect 0.10. The cats-effect dependency itself depends on cats-core 1.0.1, but this version gets evicted and we end up with cats-core 1.1.0 in our classpath, which I think is how it should be.

So something like:

object server extends ScalaModule {
      def ivyDeps = Agg (
          // cats-core 1.1.0
          // cats-effect 0.10
      )
     ....
}

Now suppose I separate my code into submodules. My main module has as ivyDeps cats-core 1.1.0, and in my submodule I only need cats-effect 0.10 - which then pulls in cats-core 1.0.1 for the submodule.

So something like:

object shared extends ScalaModule {
    def ivyDeps = Agg(
        // cats-effect 0.10, which depends on cats-core 1.0.1
    )
    ....
}
object server extends ScalaModule {
      def moduleDeps = Seq(shared)
      def ivyDeps = Agg (
          // cats-core 1.1.0
      )
     ....
}

In this case mill does not evict cats-core 1.0.1 and my server.runClasspath ends up with:

 "path": ".....maven2/org/typelevel/cats-core_2.12/1.0.1/cats-core_2.12-1.0.1.jar",
 "path": ".....maven2/org/typelevel/cats-core_2.12/1.1.0/cats-core_2.12-1.1.0.jar",

which causes all sorts of strange runtime problems.

Should eviction not take place here?

@Dennis4b
Copy link
Contributor Author

Dennis4b commented Apr 2, 2018

A more straightforward example, only using cats-effect as an example, it's about the conflicting versions:

import mill._
import mill.scalalib._
import java.nio.file.Files

object server extends ScalaModule {
    def scalaVersion = "2.12.5"

    def ivyDeps = Agg (
        ivy"org.typelevel::cats-effect:0.9",
        ivy"org.typelevel::cats-effect:0.10"
    )
}

gives (correctly)

> mill show server.runClasspath | grep cats-effect
   "path": ".....maven2/org/typelevel/cats-effect_2.12/0.10/cats-effect_2.12-0.10.jar"

and

import mill._
import mill.scalalib._
import java.nio.file.Files

object shared extends ScalaModule {
    def ivyDeps = Agg (
        ivy"org.typelevel::cats-effect:0.9"
    )
}

object server extends ScalaModule {
    def moduleDeps = Seq(shared)

    def ivyDeps = Agg (
        ivy"org.typelevel::cats-effect:0.10"
    )
}

gives (unexpectedly, at least to me):

> mill show server.runClasspath | grep cats-effect
        "path": ".....maven2/org/typelevel/cats-effect_2.12/0.9/cats-effect_2.12-0.9.jar",
        "path": ".....maven2/org/typelevel/cats-effect_2.12/0.10/cats-effect_2.12-0.10.jar",

@francisdb
Copy link
Contributor

I think this is a duplicate of #211 which was fixed recently (but not released yet)

@Dennis4b
Copy link
Contributor Author

Dennis4b commented Apr 2, 2018

Ah yes it appears to be. Sorry, didn't see it among the (open) issues. Great that it's fixed!

@lihaoyi lihaoyi closed this as completed Apr 4, 2018
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

3 participants