-
-
Notifications
You must be signed in to change notification settings - Fork 371
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Version conflicts and evictions when combining submodules #273
Comments
A more straightforward example, only using
gives (correctly)
and
gives (unexpectedly, at least to me):
|
I think this is a duplicate of #211 which was fixed recently (but not released yet) |
Ah yes it appears to be. Sorry, didn't see it among the (open) issues. Great that it's fixed! |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
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 onorg.typelevel cats-core 1.1.0
and oncats-effect 0.10
. Thecats-effect
dependency itself depends oncats-core 1.0.1
, but this version gets evicted and we end up withcats-core 1.1.0
in our classpath, which I think is how it should be.So something like:
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 needcats-effect 0.10
- which then pulls incats-core 1.0.1
for the submodule.So something like:
In this case
mill
does not evictcats-core 1.0.1
and myserver.runClasspath
ends up with:which causes all sorts of strange runtime problems.
Should eviction not take place here?
The text was updated successfully, but these errors were encountered: