com-lihaoyi / mill

Mill is a fast JVM build tool that supports Java and Scala. 2-3x faster than Gradle and 5-10x faster than Maven for common workflows, Mill aims to make your project’s build process performant, maintainable, and flexible
https://mill-build.org/
MIT License
2.04k stars 331 forks source link

[BSP only] `ScalaModule with RootModule` fails on Scala 3 #2629

Open lolgab opened 1 year ago

lolgab commented 1 year ago
// build.sc
import mill._, scalalib._

object root extends RootModule with ScalaModule {
  def scalaVersion = "3.3.0"
}

Only when using BSP, Metals output gives this output:

[27/33] enablePluginScalacOptions.super.mill.scalalib.ScalaModule.enablePluginScalacOptions | Downloading [2/2] artifacts (~0/0 bytes)
1 targets failed
enablePluginScalacOptions.super.mill.scalalib.ScalaModule.enablePluginScalacOptions 
Resolution failed for 1 modules:
--------------------------------------------
  com.lihaoyi:scalac-mill-moduledefs-plugin_3.3.0:0.10.9 
        not found: /Users/lorenzo/.ivy2/local/com.lihaoyi/scalac-mill-moduledefs-plugin_3.3.0/0.10.9/ivys/ivy.xml
        not found: https://repo1.maven.org/maven2/com/lihaoyi/scalac-mill-moduledefs-plugin_3.3.0/0.10.9/scalac-mill-moduledefs-plugin_3.3.0-0.10.9.pom

--------------------------------------------

For additional information on library dependencies, see the docs at
https://mill-build.com/mill/Library_Dependencies.html

It is trying to download the scalac plugin for scala 3. Does it mean that you can only have RootModules for Scala versions that are supported in the Mill build?

EDIT: RootModule with ScalaModule supports Scala 3 but BSP doesn't work correctly.

lefou commented 1 year ago

It is trying to download the scalac plugin for scala 3. Does it mean that you can only have RootModules for Scala versions that are supported in the Mill build?

This is the only option that makes sense. The root module is supposed to be loaded into the Mill classpath. It's the same with all Mill plugins.

Technically, we could support writing plugins and extension in other (compatible) Scala versions, but defining targets currently involves macros which only work for Scala 2.13, so we're not there yet.

lihaoyi commented 1 year ago

I don't think that's quite right. The MillBuildRootModule in the mill-build/build.sc is loaded in the Mill classpath and all, the RootModule in build.sc is just another module you can call targets on un-prefixed. It should not be pulling in Mill dependencies. It shouldn't even need to be a ScalaModule at all, and if the snippet given above fails that's definitely a bug

lihaoyi commented 1 year ago

FWIW, I just tested this in the Mill repo, and it seems to work as expected with a RootModule with ScalaModule

lihaoyi mill$ git diff
diff --git a/example/basic/1-simple-scala/build.sc b/example/basic/1-simple-scala/build.sc
index e2b35765e9..3d8b51fbbc 100644
--- a/example/basic/1-simple-scala/build.sc
+++ b/example/basic/1-simple-scala/build.sc
@@ -2,10 +2,10 @@
 import mill._, scalalib._

 object foo extends RootModule with ScalaModule {
-  def scalaVersion = "2.13.11"
+  def scalaVersion = "3.3.0"
   def ivyDeps = Agg(
-    ivy"com.lihaoyi::scalatags:0.8.2",
-    ivy"com.lihaoyi::mainargs:0.4.0"
+    ivy"com.lihaoyi::scalatags:0.12.0",
+    ivy"com.lihaoyi::mainargs:0.5.0"
   )

   object test extends ScalaTests {
lihaoyi mill$ ./mill -i dev.run example/basic/1-simple-scala run --text hello
[1605/1605] dev.run
[info] compiling 1 Scala source to /Users/lihaoyi/Github/mill/example/basic/1-simple-scala/out/mill-build/compile.dest/classes ...
[info] done compiling
[info] compiling 1 Scala source to /Users/lihaoyi/Github/mill/example/basic/1-simple-scala/out/compile.dest/classes ...
[warn] there was 1 deprecation warning; re-run with -deprecation for details
[warn] one warning found
[info] done compiling
<h1>hello</h1>

Using the dev.assembly gives the same results. @lolgab where are you seeing this failure?

lefou commented 1 year ago

I don't think that's quite right. The MillBuildRootModule in the mill-build/build.sc is loaded in the Mill classpath and all, the RootModule in build.sc is just another module you can call targets on un-prefixed. It should not be pulling in Mill dependencies. It shouldn't even need to be a ScalaModule at all, and if the snippet given above fails that's definitely a bug

Yeah, you're right. I mixed up MillBuildRootModule with RootModule.

lolgab commented 1 year ago

You are both right. I can't reproduce on Mill CLI. I noticed that this happens only when using BSP. So something is not right in BSP only.

KaranAhlawat commented 1 year ago

I stumbled upon this today myself, and for me, if I make the module extend RootModule, and then I try to do mill compile or mill run from the CLI, that also fails with the same error as originally stated.

lihaoyi commented 1 year ago

@KaranAhlawat can you minimize a repro so we can investigate it?

KaranAhlawat commented 1 year ago

It seems to have mysteriously fixed itself... Sorry for the unnecessary noise

lolgab commented 1 year ago

I've seen the same behaviour. It's somewhat intermittent.

lefou commented 1 year ago

I have some suspicion, since I currently try to adapt GenIdea to the new bootstrap process. It's unvalidated, but maybe we should check it. It could be, we sometimes use the wrong evaluator when evaluating tasks. E.g. in BSP, we search for all root modules and transitively collect other modules, then we only keep them for later resolution of sources, resources and classpaths. But depending on the root module, we need to use different evaluators (evaluator configs, e.g. root directory, classpath, etc.). I'm not sure this is always the case.

lihaoyi commented 1 year ago

Huh ok. I'm not sure what's happening, but perhaps the bootstrapping logic is putting in the wrong out folder path? Could be happening in either the BSP code path or CLI code path.

I suspect it's the BSP logic, because that would explain why i havent seen this: I'm still mostly using GenIdea

lefou commented 1 year ago

Take it with a grain of salt. I ran into this when trying to integrate the bootstrapping into GenIdea. I'm still in the middle of it. It could be, that it is better handled in BSP, but whoever tackles that issue, should validate this, as it might lead to hard-to-debug issues.

daymo commented 1 year ago

I'm seeing the same problem and I can provide an example to try out on your machines.

Metals is reporting the following: 2023.07.03 14:24:26 ERROR Mill command failed: /home/me/projects/scala/zio-scalafx/.metals/millw --mill-version 0.11.1 --import ivy:com.lihaoyi::mill-contrib-bloop: mill.contrib.Bloop/install

Download here: https://www.filemail.com/d/dpxqhpmmbuuppbx [File will be available for 7 days only.]

KaranAhlawat commented 1 year ago

I think that's a Metals thing. It's using the wrong command. See Metal's #5376.

daymo commented 1 year ago

FYI: Just upgrade Metals: Server Version for the example project to latest 0.11.12+161-977d53e3-SNAPSHOT and I see different output but same result. Here is the Metals log.

2023.07.04 07:57:55 INFO  [info] compiling 1 Scala source to /home/me/projects/scala/zio-scalafx/out/mill-build/compile.dest/classes ...
2023.07.04 07:58:00 INFO  [info] done compiling
2023.07.04 07:58:00 INFO  1 targets failed
2023.07.04 07:58:00 INFO  resolvedIvyDeps Failed to load dependencies
2023.07.04 07:58:00 INFO    not found: https://repo1.maven.org/maven2/org/openjfx/javafx-base/20/javafx-base-20-${javafx.platform}.jar
2023.07.04 07:58:00 INFO    not found: https://repo1.maven.org/maven2/org/openjfx/javafx-controls/20/javafx-controls-20-${javafx.platform}.jar
2023.07.04 07:58:00 INFO    not found: https://repo1.maven.org/maven2/org/openjfx/javafx-fxml/20/javafx-fxml-20-${javafx.platform}.jar
2023.07.04 07:58:00 INFO    not found: https://repo1.maven.org/maven2/org/openjfx/javafx-graphics/20/javafx-graphics-20-${javafx.platform}.jar
2023.07.04 07:58:00 INFO    not found: https://repo1.maven.org/maven2/org/openjfx/javafx-media/20/javafx-media-20-${javafx.platform}.jar
2023.07.04 07:58:00 INFO    not found: https://repo1.maven.org/maven2/org/openjfx/javafx-swing/20/javafx-swing-20-${javafx.platform}.jar
2023.07.04 07:58:00 INFO    not found: https://repo1.maven.org/maven2/org/openjfx/javafx-web/20/javafx-web-20-${javafx.platform}.jar
2023.07.04 07:58:01 INFO  time: ran 'mill bloopInstall' in 9.93s
2023.07.04 07:58:01 ERROR Mill command failed: /home/me/projects/scala/zio-scalafx/.metals/millw --mill-version 0.11.1 --import ivy:com.lihaoyi::mill-contrib-bloop: mill.contrib.bloop.Bloop/install

Could be indeed a Metals/Bloop problem but it seems to work with SBT.

lefou commented 1 year ago

@daymo wrote:

FYI: Just upgrade Metals: Server Version for the example project to latest 0.11.12+161-977d53e3-SNAPSHOT and I see different output but same result. Here is the Metals log.

2023.07.04 07:57:55 INFO  [info] compiling 1 Scala source to /home/me/projects/scala/zio-scalafx/out/mill-build/compile.dest/classes ...
2023.07.04 07:58:00 INFO  [info] done compiling
2023.07.04 07:58:00 INFO  1 targets failed
2023.07.04 07:58:00 INFO  resolvedIvyDeps Failed to load dependencies
2023.07.04 07:58:00 INFO    not found: https://repo1.maven.org/maven2/org/openjfx/javafx-base/20/javafx-base-20-${javafx.platform}.jar
2023.07.04 07:58:00 INFO    not found: https://repo1.maven.org/maven2/org/openjfx/javafx-controls/20/javafx-controls-20-${javafx.platform}.jar
2023.07.04 07:58:00 INFO    not found: https://repo1.maven.org/maven2/org/openjfx/javafx-fxml/20/javafx-fxml-20-${javafx.platform}.jar
2023.07.04 07:58:00 INFO    not found: https://repo1.maven.org/maven2/org/openjfx/javafx-graphics/20/javafx-graphics-20-${javafx.platform}.jar
2023.07.04 07:58:00 INFO    not found: https://repo1.maven.org/maven2/org/openjfx/javafx-media/20/javafx-media-20-${javafx.platform}.jar
2023.07.04 07:58:00 INFO    not found: https://repo1.maven.org/maven2/org/openjfx/javafx-swing/20/javafx-swing-20-${javafx.platform}.jar
2023.07.04 07:58:00 INFO    not found: https://repo1.maven.org/maven2/org/openjfx/javafx-web/20/javafx-web-20-${javafx.platform}.jar
2023.07.04 07:58:01 INFO  time: ran 'mill bloopInstall' in 9.93s
2023.07.04 07:58:01 ERROR Mill command failed: /home/me/projects/scala/zio-scalafx/.metals/millw --mill-version 0.11.1 --import ivy:com.lihaoyi::mill-contrib-bloop: mill.contrib.bloop.Bloop/install

Could be indeed a Metals problem but it seems to work with SBT.

This looks like something completely different to me. Also, this issue is about mill.bsp.BSP, whereas your issue involves mill.contrib.bloop, which is not using Mill's BSP server at all. Can you please open a separate issue?

daymo commented 1 year ago

@lefou Sure. See #2649

nornagon commented 1 year ago

FWIW I am seeing this on a blank project with this build.sc:

import mill._, scalalib._

object main extends RootModule with ScalaModule {
  def scalaVersion = "3.3.0"
}

and running

$ ./millw mill.bsp.BSP/install
$ ./millw run
lefou commented 1 year ago

FWIW I am seeing this on a blank project with this build.sc:

import mill._, scalalib._

object main extends RootModule with ScalaModule {
  def scalaVersion = "3.3.0"
}

and running

$ ./millw mill.bsp.BSP/install
$ ./millw run

I can't reproduce. Here's my output:

08:36:21 ⌁ lefou:/tmp $ mkdir mill-bsp
08:36:24 ⌁ lefou:/tmp $ cd mill-bsp/
08:36:27 ⌁ lefou:/tmp/mill-bsp $ nano build.sc
08:36:36 ⌁ lefou:/tmp/mill-bsp 7s $ mill mill.bsp.BSP/install
No mill version specified.
You should provide a version via '.mill-version' file or --mill-version option.
Retrieving latest mill version ...
Using mill version 0.11.1
[build.sc] [41/49] compile 
[info] compiling 1 Scala source to /tmp/mill-bsp/out/mill-build/compile.dest/classes ...
[info] done compiling
[2/2] mill.bsp.BSP.install 
Creating BSP connection file: /tmp/mill-bsp/.bsp/mill-bsp.json
08:37:21 ⌁ θ64° lefou:/tmp/mill-bsp 17s $ mill run
No mill version specified.
You should provide a version via '.mill-version' file or --mill-version option.
Using mill version 0.11.1
[36/48] finalMainClass 
1 targets failed
finalMainClass No main class specified or found
08:37:30 ⌁ lefou:/tmp/mill-bsp 3s 1 $ 

The error message means there is no main class defined, which is expected and happens after resolution.

@nornagon Can you provide your output?

nornagon commented 1 year ago

Oof, yeah, turns out like the other folks in this thread, I can't reliably reproduce this :(

It did happen repeatedly in my initial project until I rm -rf out and rebuilt. After that things seem fine.