New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
milessabin opened this Issue Feb 21, 2017 · 30 comments

Comments

Projects
None yet
@milessabin
Copy link
Member

milessabin commented Feb 21, 2017

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,

@milessabin milessabin changed the title Switch projects which use CrossVersion.full to CrossVersion.patch Switch projects which use CrossVersion.full/"org.scala-lang" to CrossVersion.patch/scalaOrganization.value Feb 21, 2017

@ghost

This comment has been minimized.

Copy link

ghost commented Feb 21, 2017

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

@milessabin

This comment has been minimized.

Copy link
Member

milessabin commented Feb 21, 2017

@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 ghost referenced this issue Feb 21, 2017

Closed

Switch to CrossVersion.patch #3

@ghost

This comment has been minimized.

Copy link

ghost commented Feb 21, 2017

Added new issue typelevel/sbt-tls-crossproject#3

@tpolecat

This comment has been minimized.

Copy link
Member

tpolecat commented Feb 21, 2017

  • doobie
@ClydeMachine

This comment has been minimized.

Copy link

ClydeMachine commented Feb 22, 2017

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

This comment has been minimized.

Copy link

ClydeMachine commented Feb 22, 2017

Grabbed typelevel/algebra as well.

@ghost

This comment has been minimized.

Copy link

ghost commented Feb 24, 2017

sbt-tls-crossproject done, thanks to @rilut for that 👍

@ClydeMachine

This comment has been minimized.

Copy link

ClydeMachine commented Feb 24, 2017

@Atry

This comment has been minimized.

Copy link

Atry commented Mar 2, 2017

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

@milessabin

This comment has been minimized.

Copy link
Member

milessabin commented Mar 2, 2017

@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

This comment has been minimized.

Copy link

Atry commented Mar 2, 2017

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

@rossabaker

This comment has been minimized.

Copy link
Member

rossabaker commented Mar 4, 2017

  • http4s
@tpolecat

This comment has been minimized.

Copy link
Member

tpolecat commented Mar 4, 2017

  • tut

meddulla pushed a commit to meddulla/scalacheck-shapeless that referenced this issue Mar 5, 2017

@meddulla

This comment has been minimized.

Copy link

meddulla commented Mar 5, 2017

  • scalacheck-shapeless
@etorreborre

This comment has been minimized.

Copy link

etorreborre commented Mar 7, 2017

  • specs2 (3.8.9)
@lambdista

This comment has been minimized.

Copy link

lambdista commented Mar 8, 2017

@sh0hei

This comment has been minimized.

Copy link

sh0hei commented Mar 8, 2017

  • argonaut-shapeless
@sh0hei

This comment has been minimized.

Copy link

sh0hei commented Mar 9, 2017

  • pureconfig
@larsrh

This comment has been minimized.

Copy link
Member

larsrh commented Mar 10, 2017

@DanielaSfregola

This comment has been minimized.

Copy link

DanielaSfregola commented Mar 17, 2017

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

Atry added a commit to Atry/scala-js that referenced this issue May 18, 2017

@sjrd

This comment has been minimized.

Copy link

sjrd commented May 19, 2017

So, I received this PR in Scala.js: scala-js/scala-js#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

This comment has been minimized.

Copy link

dwijnand commented May 19, 2017

/cc @lrytz who had the same concern in March (scala/scala-dev#252 (comment))

@lrytz

This comment has been minimized.

Copy link

lrytz commented May 19, 2017

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

@sjrd

This comment has been minimized.

Copy link

sjrd commented May 19, 2017

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

This comment has been minimized.

Copy link

ghost commented May 19, 2017

ref scalacenter/advisoryboard#20 (comment)
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

This comment has been minimized.

Copy link

Atry commented May 19, 2017

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

@sjrd

This comment has been minimized.

Copy link

sjrd commented May 19, 2017

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

This comment has been minimized.

Copy link

Atry commented May 19, 2017

I think there is a dependsOn method in sbt

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

This comment has been minimized.

Copy link

sjrd commented May 19, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment