Switch projects which use CrossVersion.full/"org.scala-lang" to CrossVersion.patch/scalaOrganization.value

[milessabin]

Please note: the list of projects below is not complete — add any projects you think might benefit from being built and tested with Typelevel Scala

To use Typelevel Scala versions which are not exactly aligned with the corresponding Lightbend Scala version (ie. because they include an additional -bin-patch-nnn suffix in their version) we need to modify project builds which use CrossVersion.full (which includes the suffix) to use CrossVersion.patch (which doesn't) where appropriate (eg. for macro-paradise and other compiler plugins).

Please note that CrossVersion.patch was added in SBT 0.13.13, so projects which aren't already on that version will also need to be upgraded to that version or later.

We must also replace explicit compiler dependencies of the form,

"org.scala-lang" % "scala-reflect" % scalaVersion.value % "provided"
"org.scala-lang" % "scala-compiler" % scalaVersion.value % "provided"

with dependendencies parametrized by scalaOrganization,

scalaOrganization.value % "scala-reflect" % scalaVersion.value % "provided"
scalaOrganization.value % "scala-compiler" % scalaVersion.value % "provided"

The general form of the changes are as shown in the completed/PR'd examples below ...

Please add projects and their status to this list,

• [x] algebra — https://github.com/typelevel/algebra/pull/202
• [x] argonaut — https://github.com/argonaut-io/argonaut/pull/271
• [x] argonaut-shapeless — https://github.com/alexarchambault/argonaut-shapeless/pull/86
• [x] cats — https://github.com/typelevel/cats/pull/1541
• [x] circe — https://github.com/circe/circe/pull/580
• [x] config — https://github.com/lambdista/config/pull/9
• [x] discipline — no changes needed
• [x] dogs — https://github.com/stew/dogs/pull/88
• [x] doobie — https://github.com/tpolecat/doobie/pull/472
• [x] finch — https://github.com/finagle/finch/pull/756
• [x] fs2 — https://github.com/functional-streams-for-scala/fs2/pull/820
• [x] http4s — https://github.com/http4s/http4s/pull/942
• [x] kittens — https://github.com/milessabin/kittens/pull/35
• [x] libisabelle – larsrh/libisabelle@453a5e42386476da0856f65656681527fca05df7
• [x] monix — https://github.com/monix/monix/pull/323
• [x] monocle — https://github.com/julien-truffaut/Monocle/pull/506
• [x] pureconfig — https://github.com/melrief/pureconfig/pull/158
• [x] refined — https://github.com/fthomas/refined/pull/261
• [x] sbt-sensible — https://github.com/fommil/sbt-sensible/pull/8
• [x] sbt-tls-crossproject — https://github.com/typelevel/sbt-tls-crossproject/issues/3
• [x] scalacheck — no changes needed
• [x] scalacheck-shapeless — https://github.com/alexarchambault/scalacheck-shapeless/pull/57
• [x] scalaz — https://github.com/scalaz/scalaz/pull/1325
• [x] scodec — https://github.com/scodec/scodec/pull/96
• [x] seals — https://github.com/durban/seals/pull/52
• [x] shapeless — https://github.com/milessabin/shapeless/commit/546f0453cb64b09758d6c83dc8eaee1db6fc8684
• [x] shapeless-contrib — https://github.com/typelevel/shapeless-contrib/pull/41
• [x] singleton-ops — https://github.com/fthomas/singleton-ops/pull/28
• [x] slickless — no changes needed
• [x] specs2 — https://github.com/etorreborre/specs2/commit/b16c2af6cd58935f356fe7c210e36d464fd1d53c
• [x] spire — https://github.com/non/spire/pull/638
• [x] spray-json-shapeless — https://github.com/fommil/spray-json-shapeless/pull/34
• [x] tut — https://github.com/tpolecat/tut/pull/146
• [ ] frameless
• [ ] scalatest

[ghost]

Would this also be applicable to sbt plugins? eg: TlsJvmCrossProject and TlsJsCrossProject

[milessabin]

@BennyHill it would only be necessary if you wanted to build an SBT plugin with TLS. But even if that's unlikely it does no harm, so why not?

[ghost]

Added new issue https://github.com/BennyHill/sbt-tls-crossproject/issues/3

[tpolecat]

• [x] doobie

[ClydeMachine]

I see shapeless-contrib looks to be using SBT 0.13.13 and isn't in the above list, yet fits the criteria to be changed. Made a PR there all the same in case that fits the bill.

[ClydeMachine]

Grabbed typelevel/algebra as well.

[ghost]

sbt-tls-crossproject done, thanks to @rilut for that :+1:

[ClydeMachine]

• [x] algebra

[Atry]

Will https://github.com/milessabin/macro-compat switch to typelevel Scala?

[milessabin]

@Atry There isn't a TLS for 2.10.x so even if there was a need for it (is there?) it isn't possible.

[Atry]

So will shapeless drop the support for 2.10 after switching to TLS?

[rossabaker]

• [X] http4s

[tpolecat]

• [x] tut

[ClydeMachine]

• [x] refined

[meddulla]

• [x] scalacheck-shapeless

[etorreborre]

• [x] specs2 (3.8.9)

[lambdista]

• [x] config

[sh0hei]

• [x] argonaut-shapeless

[sh0hei]

• [x] pureconfig

[larsrh]

• [x] libisabelle – larsrh/libisabelle@453a5e42386476da0856f65656681527fca05df7

[DanielaSfregola]

Opened PR spray-json-shapeless: see https://github.com/fommil/spray-json-shapeless/pull/34

[sjrd]

So, I received this PR in Scala.js: https://github.com/scala-js/scala-js/pull/2954 I understand you want all compiler plugins to use CrossVersion.patch so that they can be resolved even when scalaVersion is of the form 2.xx.yy-bin-whatever, as if it were 2.xx.yy.

However, for that to be meaningful, there must be a guarantee that 2.xx.yy-bin-whatever (from any organization, mind!) is backwards binary compatible with Lightbend Scala 2.xx.yy. Is there such a guarantee? I have never seen one being spelled out.

If there's no such guarantee, the dependency would resolve but it would be a lie, as it would crash with obscure LinkageErrors.

[dwijnand]

/cc @lrytz who had the same concern in March (https://github.com/scala/scala-dev/issues/252#issuecomment-285312504)

[lrytz]

https://gitter.im/typelevel/scala?at=58e1e0df8fcce56b20c443e3 for an example where this (I think) caused breakage

[sjrd]

That definitely looks like something related, yes.

IMO in general we cannot use CrossVersion.patch, as it is too lenient. In typical "user" builds it might be OK, but in the Scala.js sbt plugin that declares the dependency on the Scala.js compiler plugin, it is too weak. From where I stand, I see two paths forward:

• Either someone publishes the Scala.js compiler plugin (and the Scala.js JUnit compiler plugin) for releases of Typelevel Scala, or
• Something is done in the Typelevel Scala build that ensures it stays backwards binary compatible with Lightbend Scala, and then we could use CrossVersion.patch if scalaOrganization.value is org.typelevel

The second solution is hacky. It wouldn't scale to other versioning schemes from other organizations, etc. The first one is the cleanest, but requires more releases of the Scala.js compiler plugin, and we definitely don't have the CPUs to add Typelevel builds of Scala.js to our CI. Someone else than us could publish Scala.js compiler plugins recompiled for Typelevel, but then we would also need to provide a setting to configure the "scalaJSOrganization" in addition to scalaOrganization.

[ghost]

ref https://github.com/scalacenter/advisoryboard/pull/20#issuecomment-302340571 Proposal: Prioritize and collate sbt/scala/dbuild/community-build issues for community projects

This is a perfect example, no?

And what about scala.native, https://github.com/typelevel/sbt-tls-crossproject, etc ?

[Atry]

Option 3: Release compiler plugins as source code instead of Java bytecode, like what sbt's compiler interface did.

[sjrd]

But for that you'll need a lot of infrastructure in sbt, which we don't have now.

It also assumes that compiler plugins have the exact same sources for all versions of Scala. This is true for the Scala.js compiler plugin, through significant cleverness that would scare a lot of people away. But it's not true for all compiler plugins, notably macro-paradise.

[Atry]

I think there is a dependsOn method in sbt

dependsOn(ProjectRef(uri("git://github.com/xxx/xxx.git"), "subproject"))

[sjrd]

That assumes it's easy and fast to load the given repo, its build, and compile that project. For significant compiler plugins like Scala.js and paradise, this is far from being true.