Metals doesnt build project with project references to relative paths

[benhutchison]

Describe the bug

When a SBT project (p1) is opened that depends on another project (p2) using a relative path eg ProjectRef(file("../p2")), Metals is unable to build the project even when SBT manages fine.

To Reproduce Steps to reproduce the behavior:

clone https://github.com/benhutchison/metals_import_test

When a SBT project (p1) is opened that depends on another project (p2) using a relative path eg ProjectRef(file("../p2")), Metals is unable to build the project even when SBT manages fine. So no SematicDB is created and the IDE code navigation features dont work.

Expected behavior

Project imports P1 & P2

Installation:

• Operating system: macOS
• VSCode version: 1.30.2
• VSCode extension version: 1.2
• Metals version: 0.4

[gabro]

Hi @benhutchison, thanks for reporting! I've transferred the issue to the main Metals repo since this doesn't look extension-related.

[olafurpg]

@benhutchison Thanks for reporting! Can you maybe try to manually export the build with sbt-bloop and the following sbt settings

// Note that this task has to be scoped globally
bloopAggregateSourceDependencies in Global := true

See https://scalacenter.github.io/bloop/docs/build-tools/sbt#enable-sbt-project-references

We might be able to enable this setting by default in the metalsEnable command, but it would be good to confirm with @jvican why it's not enabled by default in sbt-bloop.

[olafurpg]

Please reopen if bloopAggregateSourceDependencies in Global := true doesn't fix the issue.

[benhutchison]

I dont think this be closed as "Resolved"... "Wont Fix" maybe...

Yes, I can confirm adding bloopAggregateSourceDependencies in Global := true does enable the metals import to complete.

However two problems remain:

1. Our sbt builds don't currently use bloop, and so that setting isnt recognized in the build file. So while adding that setting fixes the metals import, it then means SBT or Intellij users cannot open the project.

2. After importing into Metals, the user experience of working with a project with relative project-dependencies is not good.

• I cannot see/browse any files from the depended-upon project (p2) in my provided example.
• Refs to the other project are not resolved correctly and appear in red.

Please compare the UI experience in Metals vs Intellij; I have uploaded screenshots of the sample project imported into both. You can see that Intellij presents the second project as a full peer of the top-level project, whereas the Metals experience confuses me and I cant do anything useful relating to the relative p2 project.

Import Experience in Metals:

Import Experience in Intellij:

[olafurpg]

@benhutchison Thanks for the update. I agree this can be improved.

1. Our sbt builds don't currently use bloop, and so that setting isnt recognized in the build file. So while adding that setting fixes the metals import, it then means SBT or Intellij users cannot open the project.

This can be solved by making sbt metalsEnable automatically configure bloopAggregateSourceDependencies (we already do that for downloading library sources). cc/ @jvican any reason source dependencies are not enabled by default?

I cannot see/browse any files from the depended-upon project (p2) in my provided example.

This could be fixed in the vscode extension by attaching a new workspace folder. You can already do this manually https://code.visualstudio.com/docs/editor/multi-root-workspaces

There's no endpoint in LSP for servers to register new workspace folders, only to read existing ones https://microsoft.github.io/language-server-protocol/specification#workspace_workspaceFolders We could add a new client command for it like here https://scalameta.org/metals/docs/editors/new-editor.html#metals-client-commands

Refs to the other project are not resolved correctly

I am able to reproduce with your minimal repo (thanks!). This is a metals/semanticdb bug, fixing it requires rethinking assumptions we make about the structure of a project. I don't have a solution at the top of my head but I'm sure we can come up with something.

Refs to the other project appear in red

I'm unable to reproduce.

The best place to drill down this issue is to report in scalacenter/bloop with a reproduction using the bloop cli.

$ cd p1
$ bloop compile root
Compiling root (1 Scala source)
[E] [E1] src/main/scala/p1.scala:3:16
[E]      value xxx is not a member of object P2
[E]      L3:     println(P2.xxx)
[E]                      ^^^^^^
[E] src/main/scala/p1.scala: L3 [E1]

[olafurpg]

I've split this issue into two feature requests (scalameta/metals-feature-requests#14, scalameta/metals-feature-requests#15) and one bug report (#524)

[jvican]

1. So while adding that setting fixes the metals import, it then means SBT or Intellij users cannot open the project.

Why can't they open the project? Sbt-bloop is compatible with the intellij logic extracting the build, I use this logic myself in Bloop to code in IntelliJ. I would love to have some more info because if you're experiencing an error it should be fixed 😉

[renevangsgaardjp]

I just discovered a behaviour similar to this. With Metals version 0.10.5 I am not able to build the repository mentioned in the bug report, https://github.com/benhutchison/metals_import_test.

[benhutchison]

@jvican Realise I'd missed your question amongst all the github notifications, and recent activity reminded me.

My context is a bit fuzzy on this but I guessing I meant that SBT projects that dont include sbt-bloop plugin can't set that bloopAggregateSourceDependencies setting. In an organization, telling your tech lead (who doesnt use Metals) that every SBT project needs to add a plugin just so you can use a different IDE is quite an ask.

[tgodzik]

I think Bloop already sets bloopAggregateSourceDependencies as the default, so it should work 🤔