Remove launcher modules?
alexarchambault opened this issue · 9 comments
IIUC the launcher modules allow to spawn a Bloop server and open a BSP connection to it. As far as I know, Metals is its only user (as the other Bloop modules depending on it actually don't, see #1751).
These modules are often a source of transient errors on the CI, and these could advantageously be substituted by the blooprifle module from Scala CLI. A benefit of blooprifle is that it doesn't depend on any Bloop modules, and has actually very few dependencies (mainly bsp4j, libdaemon-jvm, and snailgun, the latter two having no dependencies apart from scala-library). One drawback is that it requires Java 17 as of now (for its domain socket support), although that can probably be addressed if needed (if users only connect to Bloop and its BSP sockets via TCP).
These modules also make the Bloop build more complex, as these need shading, so removing them would be quite nice.
Are there any other users of these launcher modules?
(Opening this issue in the context of trying to make Scala CLI's Bloop fork and Bloop mainline here converge.)
Are there any other users of these launcher modules?
I think that Fury and seed might have used it, but both of them seem discontinued, so we should be safe to replace it.
One drawback is that it requires Java 17 as of now
This means we would need to move Metals and Bloop on JDK 17, right? I would be ok with that, but I would do it as a first step.
This means we would need to move Metals and Bloop on JDK 17, right? I would be ok with that, but I would do it as a first step.
It would work better this way, yeah. It could work on Java 8 / 11 by connecting to Bloop (nailgun and BSP connections) via TCP, but Java 17 domain sockets would be safer in both cases. Alternatively, blooprifle could offer a way to let users use ipcsocket for domain sockets on Java 8 / 11 (or the current socket module in Bloop), but just switching to Java 17 would be safer and more stable IMO.
Thinking about this, we could even go as far as removing the bloopgun modules. When moving bloop-rifle from Scala CLI to a repository of its own, it should be rather straightforward to add a CLI alongside it, and package it with native-image too (I've been setting up lots of such repositories recently, like this one, this one, this one, this one, …, it's no big deal). Scala CLI already has some nascent Bloop CLI features (scala-cli bloop {start,output,exit}).
This would move the bloop CLI launchers to the (upcoming) bloop-rifle repo.
One drawback would be that this would add extra steps to the Bloop release process: cut a release here, wait for it to be on Maven Central, then cut a release of bloop-rifle.
In the short term, we could also stop publishing a shaded bloopgun module. Not sure which projects require such a module. Bloopgun doesn't have that many dependencies, and these could even be restricted a bit more:
$ cs resolve ch.epfl.scala::bloopgun-core:latest.release -t
Result:
└─ ch.epfl.scala:bloopgun-core_2.13:latest.release -> 1.5.2-4-68105d96 (possible incompatibility)
├─ com.github.plokhotnyuk.jsoniter-scala:jsoniter-scala-core_2.13:2.4.0
│ └─ org.scala-lang:scala-library:2.13.2 -> 2.13.8
├─ io.get-coursier:interface:1.0.6
├─ io.get-coursier:interface-svm-subs:1.0.6
│ └─ io.get-coursier:interface:1.0.6
├─ me.vican.jorge:snailgun-cli_2.13:0.4.0
│ ├─ com.github.scopt:scopt_2.13:4.0.0-RC2
│ │ └─ org.scala-lang:scala-library:2.13.0 -> 2.13.8
│ ├─ me.vican.jorge:snailgun-core_2.13:0.4.0
│ │ ├─ net.java.dev.jna:jna:5.6.0
│ │ ├─ net.java.dev.jna:jna-platform:5.6.0
│ │ │ └─ net.java.dev.jna:jna:5.6.0
│ │ └─ org.scala-lang:scala-library:2.13.4 -> 2.13.8
│ └─ org.scala-lang:scala-library:2.13.4 -> 2.13.8
├─ org.scala-lang:scala-library:2.13.8
├─ org.slf4j:slf4j-nop:1.7.2
│ └─ org.slf4j:slf4j-api:1.7.2
└─ org.zeroturnaround:zt-exec:1.11
└─ org.slf4j:slf4j-api:1.7.2
It seems to me that zt-exec could be removed (seems it's only used for the line processing helpers of the output redirection of its process builder - the same kind of thing could be achieved with java.lang.ProcessBuilder). That would remove the dependencies on / the need for slf4j modules.
jsoniter-scala and coursier-interface should be quite stable (not breaking bin compat).
Some other dependencies could be removed by splitting bloopgun into bloopgun-core and bloopgun-cli say.
bloopgun-core would depend on snailgun-core (not pulling scopt), while bloopgun-cli would pull scopt (that it uses to parse command line args) and io.get-coursier:interface-svm-subs.
@alexarchambault I'm wondering if it's hard to replace launcher by bloop-riffle implementation in this repo instead of removing it here. I think the launcher is a valid module to keep it in the main repo.
@dos65 We could do that too, yeah. The only reason I'd feel slightly more comfortable putting it in a separate repo would be bloopgun: it could be moved to the bloop-rifle repo (and maybe rewritten a bit too), that would likely use Mill, and from there, it'd be straightforward to generate native binaries for all OSes (using mill-native-image, that's used by Scala CLI, but also by all its helper binaries, like scalafmt-native-image, scala-cli-signing, scala-js-cli-native-image, java-class-name, …) I'm not fond of the way it's done currently in the repo here…
Somehow, that would make the repo here become more "bloop server" than just "bloop" (in particular if we move the integrations to separate repos).
FYI VirtusLab/scala-cli#1199 basically adds a bloop CLI substitute in Scala CLI (that can be run with scala-cli bloop …, like scala-cli bloop projects or scala-cli bloop compile -w foo). It uses Scala CLI's own Bloop server though, not the one started by Bloop (mainline) itself.
It relies on bloop-rifle from Scala CLI. So we could also drop or replace the bloopgun module here.
Intellij also uses the launcher to setup a connection to bloop