Bloop: Show sbt meta projects through BSP server

[dos65]

It seems that it needs just to fix it by adding meta-build handling here

Required for scalameta/metals-feature-requests#48

[jvican]

Thank you for opening this ticket and opening a PR. Supporting meta projects is indeed supported, but not enabled by default. Add the bloop plugin to project/project/plugins.sbt and bloop will automatically export the build for you every time sbt is run.

[jvican]

The reason why https://github.com/scalameta/metals-feature-requests/issues/48 exists is that there's not a right-off-the-bat solution to access the build projects from the user build, e.g. the build projects and the user projects are treated as independent. If you follow the steps in my previous comments, you'll notice the that bloop configuration files are added to project/.bloop instead of .bloop and that's by design.

[dos65]

Oh, probably I've chosen not the clearest name and description for this issue.

Meta builds export works correctly using the steps you've mentioned. There is only one minor problem with bloop-server. On build-targets request, it always returns ScalaBuildTarget without sbt related data(autoImports) instead of SbtBuildTarget.

1219 fixes it.

[olafurpg]

I wonder if it's possible for Bloop to generate all meta builds in the toplevel .bloop/ directory 🤔 It would be nice if we can keep using a single BSP connection to deal with the entire workspace

[jvican]

@dos65 Thanks for the explanation. #1219 exports the sbt build targets via BSP but that will only work if Metals starts a BSP connection under ./project/ instead of ./ because Bloop only sources the configuration files from the ./.bloop directory, it doesn't yet source configuration files from project/.bloop and nested project directories.

The elephant in the room here is to make bloop understand configuration files of metabuilds and that's a quite non-trivial change that I'd like to implement myself. IIRC I discussed this with both @olafurpg and @jastice a while ago and we agreed this would be the course of action.

@dos65 Your PR is mergeable, will try to review it soon, but it won't be functional until I follow up with the bigger change.

[jvican]

@olafurpg Actually, I misread what you said. What bloop will do is to source config files from project/.bloop but the metabuild will not write directly to .bloop because it'd be hacky to do that and still get the automatic removal of projects that no longer exist. Making bloop understand config files from other .bloop directories seems like the best way of making it easy for BSP clients to get build information.

[dos65]

@jvican Yes, I know about several connections. I've started implementing sbt support in metals and made a lot of dirty temporary changes to allow it to works with several bsp-connections.
It would be great if bloop will allow working with all build-targets using a single connection.

However, this change is enough for me to complete a working prototype. Scala files under project directory already work, now I need to get autoImports and implement PC for .sbt files.

[dos65]

@jvican @olafurpg
I got a working version for sbt-files-support in metals.
To work around this problem with connections I've just added a hack by copying .project/.bloop/*-build.json to the root bloop directory between bloopInstall and initialize actions. It seems like it works ok.

I've also made a quick glance at bloop sources and it seems that this issue implementation isn't going to be easy.
I'm not sure but it looks like this hack from metals-side wouldn't lead to any problem because bloop uses absolute paths in config files.

So, maybe it would be enough just to merge #1219 to unblock scalameta/metals-feature-requests#48?
What do you think?

[tgodzik]

@dos65 I quickly took a look at the changes you did in Metals, it looks good!

I think an alternative to copying those json files we could go a similar route as in Ammonite PR and creating another connection. Though, I think it would also be nice to be able to have everything sent together.