unusedCompileDependenciesFilter usage
Opened this issue · 8 comments
I seemingly used unusedCompileDependenciesFilter
as specified in README.md, but got errors during sbt run
project/build.properties
sbt.version=1.2.8
project/plugins.sbt
addSbtPlugin("com.timushev.sbt" % "sbt-updates" % "0.4.0")
addSbtPlugin("com.github.cb372" % "sbt-explicit-dependencies" % "0.2.9")
build.sbt
unusedCompileDependenciesFilter -= moduleFilter("org.scalaz", "scalaz")
sbt update
error: No implicit for Remove.Value[explicitdeps.ModuleFilter, sbt.librarymanagement.ModuleFilter] found,
so sbt.librarymanagement.ModuleFilter cannot be removed from explicitdeps.ModuleFilter
unusedCompileDependenciesFilter -= moduleFilter("org.scalaz", "scalaz")
^
[error] Type error in expression
Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore? q
Apparently this is caused by including the sbt-updates plugin
If I have addSbtPlugin("com.timushev.sbt" % "sbt-updates" % "0.4.0")
in project/plugins.sbt
, I get the above error message
I'm glad you found the cause just as I was about to start looking at this 😄
It's quite surprising though. Both plugins define their own type alias for sbt.librarymanagement.ModuleFilter
(explicitdeps.ModuleFilter
and com.timushev.sbt.updates.Compat.ModuleFilter
respectively) but I wouldn't expect that to be a problem.
I'll do some digging and see if I can at least find a workaround.
thanks @cb372, this error baffles me since explicitdeps.ModuleFilter
is a type alias for sbt.librarymanagement.ModuleFilter
. I've tried some workarounds but none seemed to work
@anilkumarmyla I've found a workaround:
unusedCompileDependenciesFilter := moduleFilter() - moduleFilter("org.scalaz", "scalaz")
@cb372 It works! Have you gotten to the root cause of the behavior?
Just remembered that the documentation should also mention how to filter multiple modules rather than a single one so as to make the syntax clearer 😄
I've found the cause, and I'm an idiot. It's an ambiguous implicit.
sbt doesn't provide an instance of Remove.Value
for ModuleFilter
(maybe it should), so sbt-updates provides one here.
When I found that code in sbt-updates previously, I liked the idea and shamelessly stole it. So there's an identical instance in sbt-explicit-dependencies here, which causes an ambiguous implicit when you use both plugins. I completely forgot that I'd done that!
Interesting, I'd expect the scala compiler to throw an error/warning about the ambiguous implicit.