Update Discipline version

[travisbrown]

When the tests are run here 0.11.1 is evicted and 0.11.2-M1 is used (which is why they're working), but for cats-effect-laws users with a configuration like this:

scalaVersion := "2.12.8"

libraryDependencies ++= Seq(
  "org.scalatest" %% "scalatest" % "3.1.0-SNAP9",
  "org.typelevel" %% "cats-effect-laws" % "2.0.0-M1",
  "org.typelevel" %% "discipline" % "0.11.2-M1",
  "org.scalatestplus" %% "scalatestplus-scalacheck" % "1.0.0-SNAP4"
)

…the eviction goes the wrong way:

[info] Here are other dependency conflicts that were resolved:
[info]  * org.typelevel:discipline_2.12:0.11.1 is selected over 0.11.2-M1
[info]      +- org.typelevel:cats-effect-laws_2.12:2.0.0-M1       (depends on 0.11.1)
[info]      +- org.typelevel:cats-laws_2.12:2.0.0-M1 ()           (depends on 0.11.2-M1)
[info]      +- default:cats-effect_2.12:0.1.0-SNAPSHOT            (depends on 0.11.2-M1)
[info]      +- org.typelevel:cats-kernel-laws_2.12:2.0.0-M1 ()    (depends on 0.11.2-M1)

And then you get "missing from the classpath" errors about org.scalatest.prop.Checkers.

It's easy enough to work around this by e.g. moving the cats-effect-laws dependency to the end of the list, but it'd be better just to fix it here.

[rossabaker]

Agreed. And I don't mind the milestone dependency, because we're already in milestones to make this work. We'll get all those cleaned up before 2.0.0.

[travisbrown]

@rossabaker Out of curiosity, do you happen to know what's up with the eviction in my example here? My understanding was that unless there's some force somewhere upstream (which there's not in this case, I'm pretty sure) the older version should be evicted, and this shouldn't depend of the order of dependencies, which is what's actually happening.

[rossabaker]

No, I'm equally surprised by that behavior.

[codecov-io]

Codecov Report

Merging #524 into master will increase coverage by 3.6%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master     #524     +/-   ##
=========================================
+ Coverage   85.82%   89.43%   +3.6%     
=========================================
  Files          71       71             
  Lines        2152     2054     -98     
  Branches      150      147      -3     
=========================================
- Hits         1847     1837     -10     
+ Misses        305      217     -88

[dwijnand]

sbt adds the force. It's because it's emulating Maven's "nearest wins" semantics.

[travisbrown]

@dwijnand But I explicitly say I want 0.11.2-M1—how is that not nearest?

[dwijnand]

Because it's not forced, I think. You define you want 0.11.2-M1 and via cats-effect-laws defines it wants 0.11.1, which is forced, therefore 0.11.1 wins. At least I think that's how it happens. It's bad, I know, and it's not even new.

[travisbrown]

@dwijnand Hmm, I'm not sure I'm convinced, especially because moving "org.typelevel" %% "cats-effect-laws" % "2.0.0-M1" down two lines switches the eviction. Thanks, though. I'm happy to let it be a mystery and never think about it again.

[dwijnand]

Yeah, that makes absolutely no sense.

[djspiewak]

force breaks commutativity of the sequence of dependencies. I honestly have no idea why this is the case, but I've seen it very specifically across multiple projects. It's a thing. I don't know if it's because of a bug somewhere, and I honestly can't recall if I've seen it with Coursier or only Ivy, but I can confirm that it happens.