Mill 1.0.0 Discussion

[lihaoyi]

Thread for discussing the Mill 1.0.0 release, following up on the thread for discussing the RCs (#5189)

Changelog: https://github.com/com-lihaoyi/mill/blob/main/changelog.adoc#100

[kammoh]

Congrats on the 1.0.0 release! 🎊
Are there any plans to re-enable some sort of bloop integration?
The only reason I use bloop is that I have some log-running tasks. Using plain mill to run will "block". I won't be able to do anything else. Running another mill instance would block:

Another Mill process is running 'xyzTask', waiting for it to be done...

Even my IDE (intelliJ) which uses bsp won't be able to do correct syntax highlighting if any changes are made while a task is running.
Is there any way to achieve this using just mill? If no, would the bloop plugin be ported to 1.0.0?

[lihaoyi]

@kammoh for long-running tasks, you can use --no-build-lock when running them to disable the lock on the filesystem. That would let your tasks run without blocking Mill from doing other things, though note that any concurrency issues or race conditions that may occur are up to you to resolve

[chikei]

So this is my action summary on an almost migrated (with some setting I can just turn off now) repository from 0.12.7 to 1.0.0, hope it saves time for other people migrates:

1. migrate any $ivy plugin to new header config in build.mill. While not explicitly stated, this shall be the only syntax for plugin forward. Without migrate this first, you'll encounter weird compiler error messages.
2. source path update: from T.sources(millSourcePath / "src" / "main" / "app") to Task.Sources("src/main/app")
3. update millSourcePath find . -name "*.mill" -exec sed -i 's/millSourcePath/moduleDir/g' {} \;
4. update $file syntax find . -name "*.mill" -exec sed -i 's/import \$file\./import build\./g' {} \;
5. update ivy syntax:

find . -name "*.mill" -exec sed -i 's/ivy"/mvn"/g' {} \;
find . -name "*.mill" -exec sed -i 's/ivyDeps/mvnDeps/g' {} \;
find . -name "*.mill" -exec sed -i 's/IvyDeps/MvnDeps/g' {} \;

6. remove Agg: find . -name "*.mill" -exec sed -i 's/Agg/Seq/g' {} \; , this sed might leaves some import mill.Seq, remove it.
7. remove $package: find . -name "*.mill" -exec sed -i '/import \$packages\._/d' {} \;
8. update Task syntax:

find . -name "*.mill" -exec sed -i 's/T\./Task\./g' {} \;
find . -name "*.mill" -exec sed -E -i 's/T( ?(\(|\{))/Task\1/g' {} \;
find . -name "*.mill" -exec sed -i 's/Task\.task/Task\.Anon/g' {} \;
find . -name "*.mill" -exec sed -i 's/Task\.sources/Task\.Sources/g' {} \;
find . -name "*.mill" -exec sed -i 's/Task\.input/Task\.Input/g' {} \;
find . -name "*.mill" -exec sed -i 's/Task\.command/Task\.Command/g' {} \;
find . -name "*.mill" -exec sed -i 's/Target\[/Task.Simple\[/g' {} \;
find . -name "*.mill" -exec sed -i 's/Command\[/Task.Command\[/g' {} \;
find . -name "*.mill" -exec sed -i 's/defaultCommandName/defaultTask/g' {} \;

9. after above you might need add import mill.Task, you might also need change both import mill.define.Target/import mill.define.Command to mill.define.Task
10. update workspace: find . -name "*.mill" -exec sed -E -i 's/Task\.workspace/BuildCtx\.workspaceRoot/g' {} \;, you might need add import mill.api.BuildCtx
11. update zinc worker:

find . -name "*.mill" -exec sed -i 's/zincWorker/jvmWorker/g' {} \;
find . -name "*.mill" -exec sed -i 's/ZincWorkerModule/JvmWorkerModule/g' {} \;

12. update mill.define namespace: find . -name "*.mill" -exec sed -i 's/import mill\.define\./import mill\.api\./g' {} \;
13. remove RootModule: find . -name "*.mill" -exec sed -i 's/RootModule with //g' {} \; (my repository has a common trait so I am searching for RootModule with BaseTrait, you might need adapt the idea to your repository convention)
14. there are no implicit wrapper object for filename.mill now, wrapper it yourself or update call name depends on needs.
15. resolveDeps() should be defaultResolver().classpath() now

[chikei]

feedback during migration:

1. can we make intellijModulePathJava available to be overriden again? My usage is that I have integration test code other than main code and unit test code in sbt layout, src/main, src/test/ and src/it.
2. while we move to more sophisticated sonaytype client, can we keep the nonstaging release code for local repository server deploy?
3. scala 3 will complain about encoded path, that should be fine? but are quite annoy for lots modules:

[build.mill-59] [warn] -- Warning: /home/Chikei/repos/mp/mailplatform/out/mill-build/generatedScriptSources.dest/support/build_/utils-network/MillMiscInfo.scala:2:15 
[build.mill-59] [warn] 2 |package build_.`utils-network`
[build.mill-59] [warn]   |               ^^^^^^^^^^^^^^^
[build.mill-59] [warn]   |The package name `utils-network` will be encoded on the classpath, and can lead to undefined behaviour.

[lefou]

1. can we make intellijModulePathJava available to be overriden again? My usage is that I have integration test code other than main code and unit test code in sbt layout, src/main, src/test/ and src/it.

We should. See also #5387 (review)

[lefou]

Opened an issue

• Remake intellijModulePathJava public #5534

[rgwilton]

A question on the 1.0.0 changelog notes please. It mentions:

interp.watch, interp.watchValue and mill.api.Workspace.workspaceRoot have been moved to a new mill.define.BuildCtx object that centralizes all these build-level APIs (https://github.com/com-lihaoyi/mill/pull/5142)

But should this be mill.api.BuildCtx rather than mill.define.BuildCtx?

[lihaoyi]

@rgwilton yes, it should be mill.api.BuildCtx

[lostiniceland]

First congrats on the 1.0 release.

I just discovered Mill and at first I was like "why do we need yet another build tool", but I must admit that I am quite intrigued by its design.

The main question for me is, how are you going to handle compatibility in the future? Having used Maven for over 15 years now (small and huge) this is the benchmark when it comes to having builds just work and especially plugin compatibility.

Gradle on the other side, which I tried to like for years now (but still dont), constantly breaks its apis, configuration and plugins (though it got better recently).
Especially when it comes to the documented plugin usage, there is often a mismatch because the plugin author has not updated how to use the plugin with a newer Gradle version. Which is totally understandable since people move on or just don't have the time anymore. Again, Maven is the benchmark where 10year old plugins still work the way they are documented.

What is your take on this?

[lihaoyi]

@lostiniceland We will maintain binary/plugin compatibility for the entire 1.x series of versions, which we hope to last at least for 2 years. The last series 0.11.x/0.12.x did manage about 2 years between plugin breakage, so this seems doable. So hopefully Mill can provide a much more stable development platform and plugin ecosystem than Gradle has been able to do

[lostiniceland]

It depends how often you plan to bump the major version. Maven is now only getting 4 while Gradle managed to be already at 8 in a lot less time.
Lets see. I am optimistic.