scala-cli
scala-cli copied to clipboard
`.bsp/scala-cli.json`'s generation ignores wrapper scripts
Version(s) 0.1.11
Describe the bug
When using a wrapper script for scala-cli, you'll see that wrapper script ignored when .bsp/scala-cli.json is generated.
For example, in Nixpkgs, the scala-cli executable maps to the following wrapper:
#! /nix/store/db7n4xkfng8y4c3klp6bjppaws3rphq6-bash-5.1-p16/bin/bash -e
export JAVA_HOME='/nix/store/qaf9wyzymdij19qxyw7208s72lajz65b-zulu17.34.19-ca-jdk-17.0.3'
exec "/nix/store/jdrnvm9rq3cniy2g0x70k0rfvx1h68rs-scala-cli-0.1.11/bin/.scala-cli-wrapped" "$@"
(.scala-cli-wrapped is the actual binary from GitHub releases)
and the bsp config gets generated as:
{
"name": "scala-cli",
"argv": [
"/nix/store/jdrnvm9rq3cniy2g0x70k0rfvx1h68rs-scala-cli-0.1.11/bin/.scala-cli-wrapped",
"bsp",
"--json-options",
"/Users/kubukoz/dev/scala-scripts/.scala-build/ide-options-v2.json",
"/Users/kubukoz/dev/scala-scripts"
],
"version": "0.1.11",
"bspVersion": "2.0.0",
"languages": [
"scala",
"java"
]
}
The point is that when you install scala-cli from Nixpkgs, it'll always use a Nix-managed Java 17. Personally I rely on this mostly to avoid the x86 release of scala-cli fetching an x86 JVM on an M1 Mac.
Why this is an issue
When I shutdown the Bloop instance started by scala-cli, and then in the future I go back to a Metals project using scala-cli, I lose the JAVA_HOME variable. scala-cli will then start Bloop using a Coursier-fetched Java 17, which will be an x86 binary, which are much much slower to run via Rosetta than an ARM-native JVM.
To Reproduce
- Wrap scala-cli in a script, any script
- Run
scala-cli compile .in a project - Look at
.bsp/scala-cli.jsonand see the wrapped program being used
Expected behaviour
Either a dealiased scala-cli is used as the first argv element, or just "scala-cli" (the command I ran when the bsp config was supposed to be generated).
Alternative - The bsp file always keeps a reference to the JVM that was available when generating it.
Some of the context of BSP is kept in .scala-build, namely in ide-inputs.json and ide-options-v2.json.
A potential fix would be to keep the JVM reference in a similar fashion, so that the IDE picks it up when needed.
Regardless, good catch.
I think my workaround for this will be to make the wrapper script override argv[0] - that should do the trick: https://github.com/NixOS/nixpkgs/pull/203653
@Gedochao sip 46 relevant