How do I use a nightly build of Scala?
Asked Answered
M

1

20

I want to test my code against the latest bleeding edge Scala 2 or Scala 3 nightly.

(Or, I want to use an experimental Scala 3 feature, which are only available in nightly builds.)

What do I do?

Misgive answered 16/11, 2016 at 2:3 Comment(0)
M
34

Scala 3

Scala 3 nightly builds are published to Maven Central. You don't need to add a special resolver.

If you know the full version number of the nightly you want to use, you can use it just like any other Scala 3 version.

One quick way to get that version number is to visit https://dotty.epfl.ch and look in the upper left corner.

Another way is to scrape Maven Central, as shown in this script: https://raw.githubusercontent.com/VirtusLab/community-build3/master/scripts/lastVersionNightly.sc

A third way is to use scala-cli, as follows.

scala-cli

You can run nightlies with:

scala-cli repl -S 3.3.nightly
scala-cli repl -S 3.nightly

Of course, not only repl works but also all the other scala-cli subcommands such as compile and run. It also works with //> directives in your script itself, for example:

//> using scala 3.nightly

Scala 2.12 or 2.13

quick version (sbt)

Global / resolvers += "scala-integration" at
  "https://scala-ci.typesafe.com/artifactory/scala-integration/"
scalaVersion := "2.13.10-bin-abcd123"

for a 2.12 nightly, substitute e.g. 2.12.18 for 2.13.10; in either case, it's the version number of the next release on that branch

for abcd123, manually substitute the first 7 characters of the SHA of the latest green build on the 2.13.x or 2.12.x branch on Travis-CI.

A quick way to find out the full version number of a current nightly is to use scala-cli, as follows.

quick version (scala-cli)

You can run nightlies with:

scala-cli repl -S 2.12.nightly
scala-cli repl -S 2.13.nightly
scala-cli repl -S 2.nightly     # same as 2.13.nightly

Of course, not only repl works but also all the other scala-cli subcommands such as compile and run. It also works with //> directives in your script itself, for example:

//> using scala 2.nightly

longer explanation

The Scala team no longer publishes -SNAPSHOT versions of Scala. (Starting that again could be a community contribution; see this ticket.)

But the team does publish nightly builds, each with its own fixed version number. The version number of a nightly looks like e.g. 2.13.1-bin-abcd123. (-bin- signals binary compatibility to sbt; all 2.13.x releases since 2.13.0 are binary compatible with each other.)

To tell sbt to use one of these nightlies, you need to do three things.

First, add the resolver where the nightlies are kept:

Global / resolvers += "scala-integration" at
  "https://scala-ci.typesafe.com/artifactory/scala-integration/"

Second, specify the Scala version:

scalaVersion := "2.13.1-bin-abcd123"

But that isn't a real version number. Manually substitute a version number containing the 7-character SHA of the last commit in the scala/scala repository for which a nightly build was published. Look at https://travis-ci.org/scala/scala/branches and you'll see the SHA in the upper right corner of the 2.13.x (or 2.12.x) section. For example:

enter image description here

As soon as 2.13.1 is released, the version number in the nightly will bump to 2.13.2, and so on.

If you have a multiproject build, be sure you set these settings across all projects when you modify your build definition. Or, you may set them temporarily in the sbt shell with ++2.13.1-bin-abcd123 (sbt 0.13.x) or ++2.13.1-bin-abcd123! (sbt 1.x; the added exclamation point is necessary to force a version not included in crossScalaVersions to be used).

Ideally, we would suggest an automated way to ask Travis-CI for the right SHA. This is presumably possible via Travis-CI's API, but (to my knowledge) nobody has looked into it yet. (Is there a volunteer?)

Note that we call these “nightly” builds informally, but technically it's a misnomer. A so-called “nightly” is built for every merged PR.

Misgive answered 16/11, 2016 at 2:3 Comment(4)
See also github.com/typelevel/scala/issues/135 ... to support compiler plugins you'll want to use CrossVersion.patch, and while you're at it you might as well use scalaOrganization.value to get Typelevel Scala compatibility too.Unplumbed
If you find you want to do this frequently, it is also possible to add conditionally add the extra resolver in your global SBT config (e.g. gist.github.com/retronym/61bfa9585a303cdaa204b5916124bf0c)Retardation
If you get an error mesage like org.scala-js#scalajs-compiler_2.12.8-bin-ebf8017;0.6.25: not found, one solution (that worked for me) is: libraryDependencies := libraryDependencies.value.filterNot(_.name == "scalajs-compiler"), addCompilerPlugin("org.scala-js" % "scalajs-compiler_2.12.7" % "0.6.25"),Dilapidated
I have also sometimes resorted to just editing the build definition and replacing "foolib" %% "1.2.3" with "foolib_2.12.7" % "1.2.3", this comes up with anything published by full Scala version, typically compiler plugins (Scala.js, macro paradise, etc)Misgive

© 2022 - 2024 — McMap. All rights reserved.