Skip to content

Version conflicts and evictions when combining submodules #273

@Dennis4b

Description

@Dennis4b

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions