Sbt doesn't propagate SBT_OPTS to the generated bsp config

[kasiaMarek]

steps

1. Set -Dsbt.boot.directory=<some_path> in SBT_OPTS env variable,
2. run sbt bspConfig,
3. run the args generated in the config sbt.json, which in my case look like this: [...]/java -Xms100m -Xmx100m -classpath [...]/sbt-launch.jar -Dsbt.script=[...]/sbt xsbt.boot.Boot -bsp.

problem

-Dsbt.boot.directory=<some_path> option doesn't seem to be propagated to args generated in the bsp config, and the launcher starting the sbt server uses the default sbt.boot.directory.

expectation

SBT_OPTS to be propagated to the generated bsp config where relevant and possibly add the necessary args to the generated config:
[...]/java -Xms100m -Xmx100m -classpath [...]/sbt-launch.jar -Dsbt.script=[...]/sbt -Dsbt.boot.directory=<some_path> xsbt.boot.Boot -bsp

notes

connected to: scalameta/metals#5796

[adpi2]

Thanks for the report!

I don't expect the SBT_OPTS to be propagated to the BSP config. However the server should read the SBT_OPTS when started by the BSP command. It is a bug if it does not.

[kasiaMarek]

However the server should read the SBT_OPTS when started by the BSP command. It is a bug if it does not.

That seems to work as expected.

I don't expect the SBT_OPTS to be propagated to the BSP config.

Is there a different way to add -Dsbt.boot.directory=<some_path> option to the bsp config permanently ? The trouble is that if you add it manually, sbt seems to regenerate the config quite a lot, and the option disappears.

[adpi2]

Is there a different way to add -Dsbt.boot.directory=<some_path> option to the bsp config permanently ?

No I don't think it is currently possible without a fix in sbt itself.

My suggestion would be to change the way sbt generates the BSP config. It should generate .../sbt -bsp instead of .../java ... xsbt.boot.Boot -bsp. That would solve your issue because the sbt script does read the SBT_OPTS env.

It would solve other issues like:

• it does not start with the current Java version in the path
• it does not use the native sbt client

[kasiaMarek]

My suggestion would be to change the way sbt generates the BSP config.

How should we generate the config then? We generate it running .../sbt bspConfig wouldn't that be the preferred way?

[adpi2]

We generate it running .../sbt bspConfig wouldn't that be the preferred way?

Yes it is.

I am suggesting to change the implementation of sbt bspConfig in sbt. The code is here:

sbt/protocol/src/main/scala/sbt/internal/bsp/BuildServerConnection.scala

Lines 26 to 61 in 48c2376

	private[sbt] def writeConnectionFile(sbtVersion: String, baseDir: File): Unit = {
	val bspConnectionFile = new File(baseDir, ".bsp/sbt.json")
	val javaHome = System.getProperty("java.home")
	val classPath = System.getProperty("java.class.path")
	val sbtScript = Option(System.getProperty("sbt.script"))
	.orElse(sbtScriptInPath)
	.map(script => s"-Dsbt.script=$script")
	// IntelliJ can start sbt even if the sbt script is not accessible from $PATH.
	// To do so it uses its own bundled sbt-launch.jar.
	// In that case, we must pass the path of the sbt-launch.jar to the BSP connection
	// so that the server can be started.
	// A known problem in that situation is that the .sbtopts and .jvmopts are not loaded.
	val sbtLaunchJar = classPath
	.split(File.pathSeparator)
	.find(jar => SbtLaunchJar.findFirstIn(jar).nonEmpty)
	.map(_.replace(" ", "%20"))
	.map(jar => s"--sbt-launch-jar=$jar")
	val argv =
	Vector(
	s"$javaHome/bin/java",
	"-Xms100m",
	"-Xmx100m",
	"-classpath",
	classPath,
	) ++
	sbtScript ++
	Vector("xsbt.boot.Boot", "-bsp") ++
	(if (sbtScript.isEmpty) sbtLaunchJar else None)
	val details = BspConnectionDetails(name, sbtVersion, bspVersion, languages, argv)
	val json = Converter.toJson(details).get
	IO.write(bspConnectionFile, CompactPrinter(json), append = false)
	}

[kasiaMarek]

Oh, yeah, sorry. I misread what you wrote.