cb372/sbt-explicit-dependencies

Same dependency is listed both as undeclared and unused.

Opened this issue · 2 comments

In one of the projects I have declared libraryDependency "co.fs2" %% "fs2-core" % "0.10.5".

It is then evicted like following:

[info] 	* co.fs2:fs2-core_2.12:0.10.6 is selected over {0.10.5, 0.10.5}
[info] 	    +- com.ovoenergy:rac-gas-loss_2.12:0.50-SNAPSHOT      (depends on 0.10.6)
[info] 	    +- co.fs2:fs2-io_2.12:0.10.6                          (depends on 0.10.6)
[info] 	    +- org.tpolecat:doobie-free_2.12:0.5.4                (depends on 0.10.6)
[info] 	    +- co.fs2:fs2-scodec_2.12:0.10.5                      (depends on 0.10.5)
[info] 	    +- co.fs2:fs2-core_2.12:0.10.5                        (depends on 0.10.5)

Which makes it both unused and undeclared from this plugin perspective:

The following libraries are declared in libraryDependencies but are not needed for compilation:
[warn]  - "ch.qos.logback" % "logback-classic" % "1.2.3"
[warn]  - "co.fs2" %% "fs2-core" % "0.10.5"
...
 The project depends on the following libraries for compilation but they are not declared in libraryDependencies:
[warn]  - "co.fs2" %% "fs2-core" % "0.10.6"

Technically it is true, but dependency eviction is unavoidable in any big enough project, which makes use of this plugin in CI pipelines impossible as it reports errors in cases like this.

cb372 commented

Thanks for the report. I'll need to check exactly what is going on here, but I agree this is pretty undesirable behaviour.

com.ovoenergy:rac-gas-loss

👀 say hello to Monty and the rest of the R&C gang from me!

@cb372 I've just hit the same on a fairly large project - and given that plugin compares the whole module ID, you need to always have your version pinned to the latest (as decided by eviction), otherwise you get this.

What makes it difficult is that if you have a Scala Steward setup, then you have the following:

  • New CE version is released, as a patch bump (PR 1)
  • New fs2 version is released which bumps its CE dependency by 1 patch version (PR 2)

PR 2 will be failing because it pins CE to previous latest, but it gets evicted - so this plugin is angry
PR 1 needs to go in first, and PR2 will need to be rebased.

Would you accept a PR that compares dependencies without taking the actual version into account? just org name and module name