Setting to customize location of build.sbt

[tyrantkhan]

Is your feature request related to a problem? Please describe.
I am frustrated because I have not just scala code in my repository. I've got frontend and infrastructure code -- each in its own subdirectory. My build.sbt lives in backend/build.sbt

Describe the solution you'd like
I would like to be able to configure a custom directory where my build.sbt can be found.

Describe alternatives you've considered
I just open up two instances of Sublime: One with my root project not running Metals & One that opens up backend/ . This works well enough, but it is a bit annoying.

Additional context
The error I get is:

WARN no build tool detected in workspace '/Users/tyrantkhan/code/scala/microservice-users-api'. The most common cause for this problem is that the editor was opened in the wrong working directory, for example if you use sbt then the workspace directory should contain build.sbt.

And I get it because build.sbt is actually in /Users/tyrantkhan/code/scala/microservice-users-api/backend

Search terms:

[geoffreyyip]

There's another benefit to this feature. I use VSCode, and many of my editor's features are based on config files located at the root. For example, my .gitignore file has .bloop/ and .metals/. If VSCode detects a .gitignore file, then it will automatically exclude those directories and files from search results.

This works when .gitignore and build.sbt at at the same level. However, if build.sbt is in a subdirectory, then I have to open VSCode at that subdirectory. VSCode no longer has a .gitignore to look at and will include all the files from .metals/ and .bloop/ in the search results again.

I can workaround this by copying the .gitignore file into the subdirectory. However, like @tyrantkhan mentioned, it is a bit annoying

[bes1002t]

I've imported multiple different projects into my vscode workspace, "Directory 1" - "Directory 10". Although adding build.sbt and .gitignore to "Directory 5" (I have about 6 different scala projects in this directory), my .metals directory is generated into "Directory 1" and my .bloob is generated into "Directory 5".

Could this be the same issue you are facing?

[tgodzik]

it might be related, but the behaviour I noticed previously was that both were generated only in one directory 🤔

[ckipp01]

There's an ongoing pr at #5033 that will help with this situation as you'll be able to "add" a root for a workspace.

Just a reminder, if there is no update on an issue, asking "is there progress on this" is sort of frowned upon. Trust that the maintainers will move this around and update when appropriate. Unless you have a concrete link to something that is being worked on that relates to the issue and are trying to tie them together, try to avoid these types of comments/questions.

[farazy1]

Thanks for getting back to me Chris, I was able to find a work around , so instead of opening the top folder of my repository, I just open the folder with build.sbt in it, everything works fine (able to debug, commit code using atlassin ), only issue is too many/log cache files being generated and even after adding it to .gitignore atlassin still shows it under the ready for commit window, regardless point taken. Thanks, Faraz

…

On Sat, Mar 25, 2023 at 5:57 AM Chris Kipp ***@***.***> wrote: There's an ongoing pr at scalameta/metals#5033 <#5033> that will help with this situation as you'll be able to "add" a root for a workspace. Just a reminder, if there is no update on an issue, asking "is there progress on this" is sort of frowned upon. Trust that the maintainers will move this around and update when appropriate. Unless you have a concrete link to something that is being worked on that relates to the issue and are trying to tie them together, try to avoid these types of comments/questions. — Reply to this email directly, view it on GitHub <#5907>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZQMGEBU3KT5MUYYQJVODL3W526PXANCNFSM4KIAIV5A> . You are receiving this because you commented.Message ID: ***@***.***>

[kasiaMarek]

Strategy:

1. differentiate between workspace folder root (workspaceFolder) and project root (projectRoot), where

• all metals info still kept in workspaceFolder/.metals
• bsp config in projectRoot/.bsp workspaceFolder/.bsp

2. allow the user to set the projectRoot via a setting
   ALT via a command

• since we support currently only workspace wide settings this won't work well for multi root (the setting would have to be a map)
  ALT switch to workspace/configuration (from didChangeConfiguration), which allows for scoping settings
• still save the projectRoot in tables (.metals) since didChangeConfiguration comes a bit after init

3. automatically search for project root (up to 2 levels deep)

CC: @tgodzik

[ckipp01]

Maybe I'm missing it, but how would 1 actually work regarding the point about the bsp config being in the projectRoot/.bsp, since those aren't checked in the user would still have to manually select that project root correct? Also note that I think if we did this it'd technically change the spec wouldn't it?

[kasiaMarek]

Maybe I'm missing it, but how would 1 actually work regarding the point about the bsp config being in the projectRoot/.bsp, since those aren't checked in the user would still have to manually select that project root correct? Also note that I think if we did this it'd technically change the spec wouldn't it?

If workspaceFolder == projectRoot it doesn't matter, 'cause it's the default. Otherwise user has to set projectRoot anyway (or 3. we automatically find it or it was set before), so I don't really see the issue here. But you're right, the spec claims something else and for .gitignore and looking for the file it's just confusing, thanks.

[kasiaMarek]

Resolved by #5769, which introduces a custom project root setting.