New features and breaking changes in 0.12.x

[lefou]

Below you find a new feature or a breakage per main-comment. Discussion should happen in the matching sub-comments.

The development of Mill 0.12 starts with the tag 0.12.0-M0 in the main branch. It is planned to keep binary compatibility to Mill 0.11, so that you can keep using plugins built for Mill 0.11. Therefore we also keep the binary platform to 0.11, which means, thirdparty plugins will keep using the _mill0.11 suffix in their artifact name.

Maintenance of Mill 0.11 will happen for a rather short time in the 0.11.x branch, as we hope that it's easy for most users to just switch over to 0.12.

Please open a new issue or a discussion, if you face major road blocks when switching from 0.11 to 0.12!

[lefou]

Mill 0.12 will requires Java 11.

• Bump Requests-Scala to 0.9.0 #3282

[lefou]

Mill 0.12 supports submodules defined in module.sc package.mill files in sub-directories.

• Support module.sc files in subfolders #3213

[lefou]

Mill 0.12 now enables parallel builds by default.

• Turn on parallelism by default, ensure Commands always run serially at the end #3265

[lihaoyi]

Mill 0.12 runs test suites with the subprocess working directory set to empty sandbox folders by default, rather than in the project root

• Make TestModule#test run in T.dest folder by default #3347

[lihaoyi]

We'll also be moving the Mill process os.pwd to a sandbox folder by default, to encourage proper use of T.sources, T.dest and PathRefs rather than directly reading files off of disk

• Move Mill process working directory to sandbox #3367

[lefou]

Dropped Support for Scala Native 0.4

• as part of Test suite overhaul #3398

[lefou]

The name of the BaseModule is no longer build, but build.package.

As a result, when using mill.resolve.Resolve.resolve API, you may need to change your code.

A possible code change might look like this:

 mill.resolve.Resolve.Tasks.resolve(
-    build,
+    build.`package`,
     taskNames,
     SelectMode.Separated
   )

[lihaoyi]

This should be no longer necessary once #3426 lands

[lefou]

Nice to see that we don't introduce extra use of package objects. While experimenting, I think I witnessed various strange incremental compiling issues caused by package objects.

[lihaoyi]

Yeah I hit a bunch of issues. I assume some are fixed in Scala3, and package objects do seem to fit the domain nicely, but some issues remain (e.g. the build.package thing) so maybe best to go eith normal objects for now

[lolgab]

forkEnv is now an empty Map #3442

[lefou]

Mill commands now require arguments to be passed named via ./mill mycommand --key value, rather than allowing just ./mill mycommand value.

You can pass in --allow-positional-command-args to fall back to the old behavior, or use @mainargs.arg(positional = true) on individual parameters

• Make Mill commands require named CLI parameters by default #3431

[lihaoyi]

The type parameter for Discover[T] was removed in 40b1920, leaving just Discover. The type parameter was unused, and removing it is binary compatible although not source compatible. For migration purposes, you should be able to convert any Discover[T] types to just Discover and things should continue working as before

[gamlerhart]

I maybe missed it somewhere, but a breaking change also?
The RootModule must now be called package.

[lefou]

Correct. And since package is a reserved keyword, you need to mask it in Scala.

object `pakcage` extends RootModule {
}

[nafg]

Couldn't that just be

package object whatever extends RootModule

?

[lefou]

@nafg No. We evaluated that, but it has issues. Also, package objects will go in Scala 3.

[lefou]

JavaModule.runIvyDeps are now transitive.

• runIvyDeps should be transitive for consistency with Maven resolution #3761
• Make runtime deps transitive #3774

[Tang-Haojin]

I have a file submodule/common.sc, and in previous version, I can use import $file.submodule.common. Now I get

[error] object submodule is not a member of package build_

How should I modify my build.mill?

[lefou]

@Emin017 What's wrong with this line? Do you have a reproducer?

[Emin017]

@lefou I'm trying to import xxx.sc from subdir (dependencies/xxx/xxx.sc) like this:

import mill._
import mill.scalalib._
import mill.scalalib.publish._
import coursier.maven.MavenRepository
import $file.dependencies.hardfloat.{common => hardfloatCommon}
import $file.dependencies.cde.{common => cdeCommon}
import $file.dependencies.diplomacy.{common => diplomacyCommon}
import $file.dependencies.chisel.{build => chiselBuild} // It seems only this import fail
import $file.{common => commonModule}

But I got the following error:

mill emulator[freechips.rocketchip.system.TestHarness,freechips.rocketchip.system.DefaultConfig].mfccompiler.compile
[build.sc-64/68] compile
[build.sc-64] [info] compiling 6 Scala sources to /home/nixos/Workbench/rocket-chip/out/mill-build/compile.dest/classes ...
[build.sc-64] [error] /home/nixos/Workbench/rocket-chip/build.sc:8:8: object build is not a member of package build_.dependencies.chisel
[build.sc-64] [error] import build_.dependencies.chisel.{build => chiselBuild}
[build.sc-64] [error]        ^
[build.sc-64] [error] /home/nixos/Workbench/rocket-chip/build.sc:32:11: not found: value chiselBuild
[build.sc-64] [error]   extends chiselBuild.Chisel {
[build.sc-64] [error]           ^

Here is my full build.sc for rocket-chip project (I'm trying to migrate it from 0.11.x to 0.12.x)

I have read some of the Mill source code, and I suspect the issue may be that Mill is skipping the search for the build.sc file in the subdirectories. However, I am still quite unfamiliar with the details of the Mill source code, so this is just my best guess. If I have made any incorrect assumptions, please accept my apologies.

[Emin017]

@Emin017 What's wrong with this line? Do you have a reproducer?

I wrote the minimal reproducible demo here: https://github.com/Emin017/mill-multi-file-bug

[lihaoyi]

Mill skips build.sc files in sub-directories because it assumes that the sub-directory belongs to a different Mill project.

Is renaming the build.sc file something else an option for you guys? Any other name would do, as long as it's not build.sc or build.mill

[Emin017]

Mill skips build.sc files in sub-directories because it assumes that the sub-directory belongs to a different Mill project.

Is renaming the build.sc file something else an option for you guys? Any other name would do, as long as it's not build.sc or build.mill

Thank you for the response! I think we should look into refactoring our build system then (Or we will have a discussion on it). And I'm very sorry for the inconvenience.

[Quafadas]

I hit a case where tests classes failed on 0.12.0, but worked on 0.11.12. Worked in CI, but not locally, which was odd.

In my build, I was adding this flag to forkArgs.

val vecIncubatorFlag = Seq("""--add-modules=jdk.incubator.vector""")

but hitting this;

1 tasks failed
vecxt.jvm.test.discoveredTestClasses java.lang.IllegalAccessError: superclass access check failed: class jdk.incubator.vector.Vector (in unnamed module @0x24e544f9) cannot access class jdk.internal.vm.vector.VectorSupport$Vector (in module java.base) because module java.base does not export jdk.internal.vm.vector to unnamed module @0x24e544f9

The workaround seems to be adding the jvm flag to mill opts, but this might be expected behaviour. Discord discussion;
https://discord.com/channels/632150470000902164/1295786923410984981/1299305997898354749

The error looks like it is coming from the Mill JVM before it forks off the test subprocess
from the discoveredTestClasses task
discoveredTestClasses runs test discovery in-process before forking off the subprocesses
not sure why it's causing issues, but you can probably solve it by adding --add-modules=jdk.incubator.vector to .mill-jvm-opts

[Quafadas]

Thank you!

…

On Wed, 13 Nov 2024 at 22:01, Tobias Roeser ***@***.***> wrote: Next Mill 0.12.3 will not longer fail in such situations. - #3954 <#3954> — Reply to this email directly, view it on GitHub <#3349 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF57BUA5ZJM5WY7JCLZ6CPD2AO4ZNAVCNFSM6AAAAABMFZ62J6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRUGYZDSOA> . You are receiving this because you commented.Message ID: ***@***.***>

[nafg]

Are there migration instructions somewhere?

[nafg]

Seems like it now reads all .sc files in the base directory?