Metals: VSCode cannot connect to bloop

[tSte]

I have VSC with this extension and running Metals: Import build ends up with this:

[E] Not a DAG, cycle detected in root -> gatling -> root 
fo  running 'sbt metalsEnable bloopInstall'
info  [info] Loading settings for project global-plugins from idea.sbt,metals.sbt ...
info  [info] Loading global plugins from /home/myUserName/.sbt/1.0/plugins
info  [info] Loading settings for project api-build from plugins.sbt ...
info  [info] Loading project definition from /home/myUserName/myApiProject/project
info  [success] Generated .bloop/api-build.json
info  [success] Total time: 6 s, completed Dec 10, 2018 2:56:19 PM
info  [info] Loading settings for project root from build.sbt ...
info  [info] Set current project to my-api-project (in build file:/home/myUserName/myApiProject/)
info  [info] Set current project to my-api-project (in build file:/home/myUserName/myApiProject/)
info  [info] semanticdb-scalac is enabled
info  [success] Generated .bloop/slickCodegen.json
info  [success] Generated .bloop/slickCodegen-test.json
info  [success] Generated .bloop/root-test.json
info  [success] Generated .bloop/root.json
info  [success] Generated .bloop/gatling.json
info  [success] Generated .bloop/gatling-test.json
info  [success] Total time: 16 s, completed Dec 10, 2018 2:56:40 PM
info  sbt exit: 0
info  time: Ran 'sbt bloopInstall' in 39s
info  running embedded 'bloop bsp --protocol local --socket /tmp/bsp6559789676998484745/1axt3poksxgc.socket'
info  bloop exit: 1
error Failed to connect with build server, no functionality will work.
scala.meta.internal.metals.BloopServers$NoResponse$: no response: bloop bsp
    at scala.meta.internal.metals.BloopServers.NoResponse$lzycompute$1(BloopServers.scala:302)
    at scala.meta.internal.metals.BloopServers.NoResponse(BloopServers.scala:302)
    at scala.meta.internal.metals.BloopServers.$anonfun$callBloopMain$1(BloopServers.scala:207)
    at scala.util.Success.$anonfun$map$1(Try.scala:255)
    at scala.util.Success.map(Try.scala:213)
    at scala.concurrent.Future.$anonfun$map$1(Future.scala:292)
    at scala.concurrent.impl.Promise.liftedTree1$1(Promise.scala:33)
    at scala.concurrent.impl.Promise.$anonfun$transform$1(Promise.scala:33)
    at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:64)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

I am on ArchLinux 4.19.8.a-1, with VSC 1.29.1.
Any idea what can cause this / how to resolve it? Thanks!

[olafurpg]

Thanks for reporting! Can see check if jars for the bloop-frontend module have downloaded to ~/.cache/coursier? Do the logs contain the following message "Failed to classload bloop"?

A possible workaround might be to install bloop directly https://scalacenter.github.io/bloop/setup

[tSte]

It doesn't contain that message (at least I can't see it - I updated logs, pls, have a look). However I don't seem to have any bloop-related stuff in ~/.cache/coursier.

Do you suggest to manually install bloop? I have it installed (from AUR). I can run it,

Unable to load nailgun-version.properties.
NGServer [UNKNOWN] started on address localhost/127.0.0.1 port 8212.

but still... it fails to connect.

[olafurpg]

I recommend installing Bloop with the instructions here https://scalacenter.github.io/bloop/setup It could be outdated on AUR

[tSte]

Nope, the same result. I even enabled bloop as service (it is active/running). Can this be caused by some access rights / restrictions of VSC to bloop? Because if I run bloop bsp --protocol local --socket /tmp/bsp6246301264379338964/gn6harancksh.socket from terminal, it seems to be working (or at least there are no exceptions thrown).

[olafurpg]

Are there any .bloop/*.json files? The logs report a warning:

�[0m�[31m[E]�[0m Not a DAG, cycle detected in root -> gatling -> root 

[tSte]

In $HOME? No. But I guess you aren't asking about this one.
In project's root .bloop dir. and in root's .project/.bloop? Yes. There are several .json and -test.json files in both. However classes and test-classes directories are all empty.

[olafurpg]

@tSte after you installed bloop, did the log message change to running installed 'bloop?

- running embedded 'bloop bsp 
+ running installed 'bloop bsp 

[tSte]

Nope, still embedded

[olafurpg]

That brings us a bit closer to see what's going on. What python do you have installed on your machine?

[tSte]

➜  ~ python
Python 3.7.1 (default, Oct 22 2018, 10:41:28) 
[GCC 8.2.1 20180831] on linux

[olafurpg]

Some thoughts:

• I'm surprised it doesn't pick up the installed bloop and continues to use the embedded more
• bloop exit: 1 in the logs indicates that the bloop bsp command exited immediately, that log should appear when the server shuts down

Something is not going as expected, but I'm afraid it's difficult to debug without being able to reproduce.

[gabro]

@tSte can you check whether you have another version of the bloop sbt plugin installed anywhere? Either globally or in your project?

I couldn't understand why it was running the embedded version on my machine, and that turned out to be the issue.

[olafurpg]

@gabro This is likely unrelated to the sbt plugin, this error happens while establishing a bsp connection

[tSte]

@gabro I don't seem to have bloop in global plugins, I have it in project:

sbt plugins | grep bloop
bloop.integrations.sbt.BloopPlugin: enabled in root

[gabro]

@gabro This is likely unrelated to the sbt plugin, this error happens while establishing a bsp connection

True, however if you have .bloop files generated by an older version of the plugin, when running this check

https://github.com/scalameta/metals/blob/07079ba80fb5206a4916f1263883e72fbbc83bfd/metals/src/main/scala/scala/meta/internal/metals/BloopServers.scala#L284

then the process will throw an error and Metals will fall back to the embedded version.

Am I reading this wrong?

@tSte which version of the bloop plugin do you have on your project?

[olafurpg]

@tSte it could be that the root of the problem is

Not a DAG, cycle detected in root -> gatling -> root 

Can try to install bloop based on https://scalacenter.github.io/bloop/ (not AUR), verify that bloop about shows v1.1.1 then try to run sbt bloopInstall. See if that works before trying to import the project with Metals. You might want to remove any .bloop/ directories first.

[tSte]

@gabro can bloop versions differ? I sort-of doubt that I had bloop installed before, so it had to be addedby metals (I didn't install bloop before)

@olafurpg I have it installed via wget and it's version is 1.1.1. sbt bloopInstall will successfully generate .json files and exits with 0.

I tried to create custom bloop.py and execute it in project's directory (since this seems to be what bloopCommandLineIsInstalled is doing). I am not sure if I should/shouldn't execute it in project's directory or somewhere else, but it exits with:

python bloop.py help
[E] Not a DAG, cycle detected in root -> gatling -> root 
Type `--nailgun-help` for help on the Nailgun CLI tool.

Does it help?

[jvican]

@tSte Could you show us your build definition? That's a fatal error that should never happen (it happens because root depends on gatling and gatling depends on root, creating a cycle; you can see that in the dependencies field of the JSON files).

A way to move forward and dignose if that's the real problem is to remove root from the dependencies in the configuration file of gatling, which you can find in .bloop/gatling.json.

[olafurpg]

@tSte thanks for the information, it seems the problem lies in bloop

• sbt bloopInstall succeeds with exit code 0
• bloop help and bloop bsp fail due to cyclic errors in the build definition

There is not much we can do on the Metals side to fix this. I recommend trying to remove the cyclic definition in the sbt build, or you can report an issue https://github.com/scalacenter/bloop

[tSte]

@jvican Unfortunately, I can't... However I can tell you that root depends on two projects (none of them are gatling) and gatling depends on root. That's all calls of .dependsOn in my build. However it's truth that gatling.json does have "dependencies": [ "root" ] and vice-versa...

Update:
I have these dependencies in root.json: ["slickCodegen", "reporting", "slickCodegen", "reporting", "gatling"]

[gabro]

Or maybe @jvican can transfer this issue to bloop's issues, since he's a member of both projects. That would be useful not to lose context

[olafurpg]

Seems you can only transfer issues within the same organization

[jvican]

However I can tell you that root depends on two projects (none of them are gatling) and gatling depends on root.

Is root depending on gatling transitively in your sbt build?

I recommend doing show $PROJECT/projectDependencies in the sbt shell for eveyr dependendency of gatling to find if your build does indeed have a cyclic dependency. Note that projectDependendencies is not transitive so you need to run it for every project dependency manually.

If the dependency is not there, I suggest you find a reproduction and create a ticket in scalacenter/bloop's issue tracker.

[tSte]

@jvican I found why... root may dependsOn other two projects, but it also has aggregate on gatling...

[jvican]

I found why... root may dependsOn other two projects, but it also has aggregate on gatling...

Yeah, that doesn't make a lot of sense :smile: Remove the aggregate and it will work.

[tSte]

@jvican yeah, it seems it will... but why is this a problem? Because aggregate and dependsOn is not the same. And I'd like to keep it that way (I want to compile gatling when compiling root too).

Note: my knowledge of SBT is limited...

[olafurpg]

@jvican has opened a PR https://github.com/scalacenter/bloop/pull/758 improving the Bloop error handling for cyclic dependencies in build definitions so issues like this will be easier to track down in the future.