Skip to content

Make build.mill Scala version configurable #5366

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

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

arturaz
Copy link
Collaborator

@arturaz arturaz commented Jun 25, 2025

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 #5097.

@arturaz
Copy link
Collaborator Author

arturaz commented Jun 25, 2025

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

@lihaoyi
Copy link
Member

lihaoyi commented Jun 25, 2025

@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
Copy link
Member

lihaoyi commented Jun 25, 2025

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

@arturaz
Copy link
Collaborator Author

arturaz commented Jun 25, 2025

@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
Copy link
Collaborator Author

arturaz commented Jun 25, 2025

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

@arturaz arturaz marked this pull request as draft June 25, 2025 10:25
@lihaoyi
Copy link
Member

lihaoyi commented Jun 25, 2025

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
Copy link
Member

lefou commented Jun 25, 2025

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
Copy link
Member

lihaoyi commented Jun 25, 2025

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
Copy link
Member

lefou commented Jun 25, 2025

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.

@arturaz arturaz force-pushed the improvement/5097-make-scala-library-version-configurable branch from 2a52dac to f782411 Compare June 25, 2025 11:12
@arturaz arturaz marked this pull request as ready for review June 25, 2025 11:13
autofix-ci bot and others added 3 commits June 25, 2025 11:14
…ke-scala-library-version-configurable' into improvement/5097-make-scala-library-version-configurable
@lihaoyi
Copy link
Member

lihaoyi commented Jun 25, 2025

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
Copy link
Member

lefou commented Jun 25, 2025

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.

@lihaoyi lihaoyi force-pushed the main branch 2 times, most recently from 1d3b959 to 3ba698a Compare July 10, 2025 04:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants