scala-cli icon indicating copy to clipboard operation
scala-cli copied to clipboard

`.bsp/scala-cli.json`'s generation ignores wrapper scripts

Open kubukoz opened this issue 3 years ago • 1 comments

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

  1. Wrap scala-cli in a script, any script
  2. Run scala-cli compile . in a project
  3. Look at .bsp/scala-cli.json and 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.

kubukoz avatar Aug 18 '22 17:08 kubukoz

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.

Gedochao avatar Aug 19 '22 06:08 Gedochao

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

kubukoz avatar Nov 29 '22 20:11 kubukoz

@Gedochao sip 46 relevant

bishabosha avatar May 08 '24 13:05 bishabosha