Make `build.mill` Scala version configurable

[arturaz]

Allows overriding the scala-library version used by build.mill via the //| mill-scala-library-version: 3.7.2-RC1 configuration frontmatter.

Tested manually.

Implements https://github.com/com-lihaoyi/mill/issues/5097.

[arturaz]

@lihaoyi I've tested this manually as there doesn't seem to be any testing infrastructure set up for other frontmatter flags?

[lihaoyi]

@arturaz the integratiom and example tests cover frontmatter flags, this one could be an example test that we embed in the Build Header Config adoc page

[lihaoyi]

Let's call it mill-scala-version? AFAIK it should affect both the library and the compiler

[arturaz]

@arturaz the integratiom and example tests cover frontmatter flags, this one could be an example test that we embed in the Build Header Config adoc page

I'll write an integration test then that:

• makes sure that the flag works
• makes sure that if you change it the build is rebuilt.

Let's call it mill-scala-version? AFAIK it should affect both the library and the compiler

It does not seem so.

from out/mill-resolve-runner:

"mill:SNAPSHOT,scala-library-version:3.7.2-RC1"
"/home/arturaz/.ivy2/local/com.lihaoyi/mill-runner-daemon_3/SNAPSHOT/jars/mill-runner-daemon_3.jar"                                                                                        
"/home/arturaz/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala3-library_3/3.7.2-RC1/scala3-library_3-3.7.2-RC1.jar"                                                                                                                              
"/home/arturaz/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala3-compiler_3/3.7.1/scala3-compiler_3-3.7.1.jar"      

[arturaz]

I guess we should make it mill-scala-version and change the compiler dependency and not the scala-library dependency?

[lihaoyi]

It should change both I assume. Scala library and compiler versions generally have to be kept in sync AFAIK, otherwise weird bugs can happen

[lefou]

I wonder what' the motivation for this change is. It might not be possible to just update the Scala version unless you're on a very older Mill version already. The compiler plugins Mill uses for it's buildfiles need to be release for newer Scala versions first, and since these plugins are maintained by Mill devs, it's very likely that they will also update the Scala version in Mill itself, once it is possible.

[lihaoyi]

The motivation is to make it possible for users to bump the scala version even before Mill does. For example, when Scala 3.8.0 is released, users may want to use it with Mill even before a new version of Mill has been released that uses it.

Before this change, Mill users can upgrade any library in their classpath - upickle, oslib, mainargs - all except scala library and compiler which are pinned. This PR should make those two upgradable as wel

[lefou]

The motivation is to make it possible for users to bump the scala version even before Mill does. For example, when Scala 3.8.0 is released, users may want to use it with Mill even before a new version of Mill has been released that uses it.

Before this change, Mill users can upgrade any library in their classpath - upickle, oslib, mainargs - all except scala library and compiler which are pinned. This PR should make those two upgradable as wel

Which most likely means, the required compiler plugins are not yet released for these Scala versions. Making the Mill meta-build fail.

[lihaoyi]

You are right that the compiler plugins are a problem. A solution would be to publish the same plugin version for new scala versions like we do for the Scala 2 compiler bridges. That would allow an older Mill version to use a newet Scala version without needing to upgrade Mill, or wait for a new Mill release that forces a Scala version upgrade

It does call into question how useful this is though. e.g. you wouldnt be able to try out Scala nightlies or RCs without getting the plugins published first, which is one of the use cases I imagined.

[lefou]

I opened a discussion a while back about source-plugins. Following that idea, the meta-meta-build could ad-hoc compile the compiler-plugin(s) for a newer Scala version, if there is none available. Sounds a bit complicated and niche, but it might be possible.