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