search

scalameta / coc-metals

Deprecated in favor of scalameta/nvim-metals
http://scalameta.org/metals/
Apache License 2.0
167 stars 24 forks source link

Regression: SBT BSP support broken after upgrade to 0.9.9 #374

Closed jan0sch closed 3 years ago

jan0sch commented 3 years ago

I just upgraded via CocUpdate to the latest version 0.9.9 and metals no longer works. Since SBT (1.4) supports BSP I've used that happily with metals and it worked like a charm. But now all I get is the following error message:

[coc.nvim] Missing valid Bloop build in .../myproject/.bloop.
  1. Did you run bloop outside of the working directory of your build?
     If so, change your current directory or point directly to your `.bloop` directory via `--config-dir`.
  2. Did you forget to generate configuration files for your build?
     Check the installation instructions https://scalacenter.github.io/bloop/setup

I removed all temporary stuff (.bsp, .metals, etc.) and re-imported but the error message stays the same and metals doesn't work. :-(

However I'm not sure if this is caused by coc-metals or by changes in metals itself.

Installation:

jan0sch commented 3 years ago

Downgrading to coc-metals 0.9.8 with metals 0.9.7 "solves" the issue.

ckipp01 commented 3 years ago

Thanks for the report @jan0sch.

So that message is actually coming straight from Bloop, so if you're using sbt BSP instead of Bloop, you shouldn't ever get it. You mentioned that you removed all the temporary stuff, but can you tell me what happens after you remove everything and open your project? I'm assuming the first thing you get is prompted to import your build? I ask because I want to understand how you're choosing to use sbt BSP. Are you using the generate-bsp-config command or the bsp-switch command?

Also, when you're seeing this error, can you send me what the doctor shows you by doing a doctor-run?

jan0sch commented 3 years ago

Hi,

thanks for your help. Actually I never actively told metals to use sbt BSP. It just used it automatically if sbt was running. Because that worked faster and more reliable than the previously used bloop approach I thought that this would be the new default. Because sometime metals would try to install bloop nonetheless I set metals.bloopSbtAlreadyInstalled to true in the config.

Upon opening a file from the project I get the usual "do you want to (i)mport project" prompt on which I always press "i" for import. Another change of behaviour I just noticed is that the project/metals.sbt file is no longer created.

The output of doctor-run is as follows:

Metals Doctor
-------------
Build server currently being used is Bloop.

These are the installed build targets for this workspace. One build target corresponds to one classpath. For example, normally one sbt project maps to two build targets: main and test.

      buildTarget      |    scalaVersion    |     diagnostics    |   gotoDefinition   |     completions    |   findReferences   |   recommendation  
------------------------------------------------------------------------------------------------------------------------------------------------------
     foobar-build      |       2.12.12      |         ✅         |         ✅         |         ✅         |         ✅         |

However this shows a completely wrong scala version (project is using 2.13.4). This first time I ran it doctor show another ouput but I didn't copy that and was unable to reproduce that.

On the positive side, thanks to your mention of the metals.bsp-switch command I was able to make the current version connect to sbt BSP and it seems to work, yeah! 8-)

Would I need to run the bsp-switch command on every project I open? (I guess yes.)

Kind regards,

Jens

ckipp01 commented 3 years ago

So yes, part of this is actually do to a bug that was fixed in Metals. You can see this here https://github.com/scalameta/metals/pull/2297. So the behavior you were experiencing before was actually a bug, but ironically was working ok for you. If I understand correctly what you want to do, I'd suggest the following.

Then every time you open this project your explicit choice to use sbt will be saved and you won't need to worry about this again. By default, we give the user Bloop as we believe it will give you a better user experience. This will remain the default until the sbt server can reach feature parity with Bloop. So yes, for every separate project you'd need to do this. In case you missed it, you can see a blog post about all of this here: https://scalameta.org/metals/blog/2020/11/06/sbt-BSP-support.html

Regarding seeing the 2.12.12 version for you build, you can find an answer for that here https://scalameta.org/metals/docs/troubleshooting/faq.html#im-using-scala-213x-but-doctor-shows-me--build-and--build-build-at-212x.

jan0sch commented 3 years ago

Thanks for the explanation. I've used bloop before but was never satisfied with it because it crashed too often and didn't co-exist well with sbt (after all you need sbt to run tests). So for my part I was really happy to have metals using the sbt backend. ;-)

However, it would be great if the default bsp could be configured in the settings like metals.bsp.default: "sbt" or so.

ckipp01 commented 3 years ago

after all you need sbt to run tests

You actually don't. Once you build is exported to Bloop, you can run all of your tests directly with Bloop.

https://scalacenter.github.io/bloop/docs/cli/reference#bloop-test

jan0sch commented 3 years ago

You actually don't. Once you build is exported to Bloop, you can run all of your tests directly with Bloop.

Thanks, good to know.