Feature Request: `bspEnabled` equivalent

[Quafadas]

SBT allows modules to opt out of inclusion into the BSP server. I believe this to be particularly useful for cross Platform projects, where much of the time compiling the other platforms places a (potentially large, often valueless) burden on whatever the BSP server is asked to do.

https://www.scala-sbt.org/1.x/docs/IDE.html

Use the following setting to opt-out some of the subprojects from BSP. bspEnabled := false

@lefou

[lefou]

I agree, that we want this feature. IMHO, this is not really related to the build configuration and rather user specific or edit-scoped, so it should be a runtime setting. While I think it should be a feature of each BSP client in the first place, I can imagine to support a config file with either include- or exclude-patterns.

(I'm pretty sure, I already answered to this or an almost identical issue, but I can't find it now. I'll update once I find it.)

[Quafadas]

As a bike shedding option, another approach could be to "opt-in" rather than opt out.

I think the BSP-server needs some config along these lines;

{"name":"mill-bsp","argv":["/opt/homebrew/bin/mill","--bsp","--ticker","false","--color","false","--jobs","1"],"millVersion":"0.12.14","bspVersion":"2.2.0-M2","languages":["java","scala","kotlin"]}

One idea would be to include a mill query specifying the modules the BSP server should use. I think this would mean that if it was changed, the user would need to restart the BSP server. However, I think they would need to do that anyway... and if they are changing the config, it feels like a natural workflow?

e.g.

{"name":"mill-bsp","argv":["/opt/homebrew/bin/mill","--bsp","--ticker","false","--color","false","--jobs","1"
""--bsp-query", "__.jvm._"
],"millVersion":"0.12.14","bspVersion":"2.2.0-M2","languages":["java","scala","kotlin"]}

Which I think would select all JVM modules?

Something I like about this, is that it's a single option as opposed to be scattered somewhere.

[lefou]

Yeah, a Mill task query is very well suited for this, since you can already express excludes (__:^TestModule) and enumerate concrete modules.

I suggested to read a file for the following reasons.

• It can be picked up automatically, if present
• It better survives IDE-initiated re-installs of the BSP server
• It's better suited for more complex queries (e.g. the Mill project has a lot of example sub-modules and integration-test sub-modules, but you probably want enable some of them depending on the use-case)

Accepting a include-pattern via a CLI arg or via file isn't mutually exclusive.

[Quafadas]

That JSON lives in the file .bsp/mill-bsp.json. If I'm reading this right, it sounds like you favour a dedicated / standalone file?

[lefou]

That JSON lives in the file .bsp/mill-bsp.json. If I'm reading this right, it sounds like you favour a dedicated / standalone file?

Yeah. We could place it in .bsp/mill-bsp-modules.json or make it a regular Mill config, which can be given as //| mill-bsp-modules header or .mill-bsp-modules or .config/mill-bsp-modules. The latter has the advantage, that our precedence-rules take place, so you can provide a project default and a local override without fighting git changes at the same time.

[lefou]

Related:

• https://github.com/com-lihaoyi/mill/issues/5344 - as we want to select modules, not tasks.

[lihaoyi]

Fixed by https://github.com/com-lihaoyi/mill/pull/6065

[lihaoyi]

This is included in the latest development release 1.0.6-114-ed0e74 containing https://github.com/com-lihaoyi/mill/pull/6065 from @alexarchambault