@Sciss you can pupulate the download cache by calling this dedicated main method https://github.com/scalameta/metals/blob/main/metals/src/main/scala/scala/meta/metals/DownloadDependencies.scala
It seems that vscode gets stuck indexing when I try to import projects with a large number of modules. Is this a known problem?
(The import works fine, but then it just says "Indexing..." in the bottom right corner forever after that.)
Could you try to run async-profiler on the metals process to see what it’s doing? https://github.com/jvm-profiling-tools/async-profiler
Hmmm... Thought I was running the latest, but according to the output panel I am using Java 11.
I'll try with a later version and see if that solves it.
sbt --client works but still has bugs with autocompletion and disconnects on Mac so
@asflierl: I believe it should, as when we compose the args to create the actual bsp file args, we do look at them https://github.com/scalameta/metals/blob/6fd19300ed684410875db340e329cb85a42c58f2/metals/src/main/scala/scala/meta/internal/builds/SbtBuildTool.scala#L83-L84
this could be that when that file is generated by sbt and not metals, it doesn't take them into account
it's worth filing an issue
@markusa380: could you elaborate a bit more? sbt server needs to be started in order for it to function as a BSP server
an alternative would be to start
sbt --client first in the workspace, then open the project in Metals if you've chose sbt as a BSP server
then it'd just connect to the already running server
To rephrase, I need to use SBT and Metals, and Metals depends on SBT, so Metals should not start SBT, because I also need SBT. So I should start SBT and Metals should pick that up, as it already does when starting SBT itself and waiting for it to boot up
It should at least be a flag one can set in the preferences that make Metals wait for a server instead of starting one.
Or, what would also work, and might solve more than just this issue, is if the command to start SBT is configurable.
well both Metals and sbt are implementing BSP here, and according to BSP discover, if a
.bsp/<server>.json file exists, that's an indication that it should be started. So in this situation when you've chosen to use sbt as a build server at some point in time and open the project, metals remembers that, follows BSP discovery rules and starts the server since it needs that in order to function
There's this setting already:
Sbt Script
Optional absolute path to an sbt executable to use for running sbt bloopInstall.
By default, Metals uses java -jar sbt-launch.jar with an embedded launcher while respecting .jvmopts and .sbtopts.
Update this setting if your sbt script requires more customizations like using environment variables.
But this is not honored.
4 replies
It should at least be a flag one can set in the preferences that make Metals wait for a server instead of starting one.
But metals would sort of be unusable until that happened
Yes of course it wouldn't be usable until that
but when sbt server is running for a workspace, it only runs once right? So does starting sbt server first and then vs code work in this scenario?
because even then, only one sbt instance would be running
So does starting sbt server first and then vs code work in this scenario?
Yes, it would, but I want to of course use the integrated terminal to avoid alt-tabbing between the windows. Most people prefer that I think.
well the way that it's launched is actually defined in your
.bsp/sbt.json file
when looking in there, I'm assuming you don't see the env variables you're looking for?
if that's the case please do submit an issue with a reproduction
Again, I'm completely okay with not having functionality until SBT is started. I just want to be able to use SBT at the same time as using Metals.
I'm still not sure I understand why you can't. Even after metals starts sbt, you should still be able to open your terminal, connect to the running server and issue commands
Because SBTN is a buggy mess.
Sometimes
I mean if sbt is your build server then compiling manually via sbt is redundant as a save in VS Code will also trigger the same compile
Especially on compile heavy projects this can get quite upsetting :(
But apart from this I want to be able to run
clean and test when I want
