Any way to detect if this launcher is being used?

[dwijnand]

I keep making the mistake of using this launcher (as it's my default) in lampepfl/dotty and later realising when it breaks.

I was thinking: can I detected if this launcher is being used, say, in the build? Perhaps I can fast-fail the onLoad and avoid myself (and others) the same mistake.

[djspiewak]

This works!

def detectedCsbt(): Boolean = {
  try {
    val klass = Class.forName("lmcoursier.definitions.ToCoursier$")
    val m = klass.getMethod("project", Class.forName("lmcoursier.definitions.Project"))
    m.getReturnType().getName == "coursier.core.Project"
  } catch {
    case _: Throwable => false
  }
}

if (detectedCsbt())
  addSbtPlugin("io.get-coursier" % "sbt-coursier" % "2.0.0-RC3-3")
else
  Seq()

Specific scenario here is I wanted to stick sbt-coursier into my global plugins, conditional on the use of the relevant launcher. This does the trick.

For posterity, the idea here comes from @dcsobral: try using a Coursier-specific plugin task (in my case, coursierDependencyTree) using the sbt-coursier plugin and the regular launcher, then build the detectedCsbt definition using the specific error which arises, which in this case is a NoSuchMethodError referring to the signature in the above.

[alexarchambault]

@djspiewak @dcsobral May I ask what makes you prefer coursierDependencyTree over sbt-dependency-graph? Not disrupting users of this key (alongside coursierDependencyInverseTree and coursierWhatDependsOn) is basically the only reason I don't discard sbt-coursier for sbt-lm-coursier. I'm not a big user of either coursierDependencyTree or sbt-dependency-graph, so I'm not sure if I should go ahead or not on that.

[djspiewak]

Dependency graph is much, much slower and also a lot harder to read. coursierDependencyTree was actually the first reason I started using Coursier, because it's far and away the best tool in the ecosystem for diagnosing weird dependency issues.