-
-
Notifications
You must be signed in to change notification settings - Fork 411
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
base: main
Are you sure you want to change the base?
Make build.mill
Scala version configurable
#5366
Conversation
@lihaoyi I've tested this manually as there doesn't seem to be any testing infrastructure set up for other frontmatter flags? |
@arturaz the integratiom and example tests cover frontmatter flags, this one could be an example test that we embed in the |
Let's call it |
I'll write an integration test then that:
It does not seem so. from
|
I guess we should make it |
It should change both I assume. Scala library and compiler versions generally have to be kept in sync AFAIK, otherwise weird bugs can happen |
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. |
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. |
2a52dac
to
f782411
Compare
…ke-scala-library-version-configurable' into improvement/5097-make-scala-library-version-configurable
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 |
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. |
1d3b959
to
3ba698a
Compare
Allows overriding the
scala-library
version used bybuild.mill
via the//| mill-scala-library-version: 3.7.2-RC1
configuration frontmatter.Tested manually.
Implements #5097.