Can Metals function without a workspace?

[oblitum]

Hi.

Before tackling this question, I urge you first to read the following thread and associated discussion carefully, as I rather not replicate it again:

• Default to parent directory if opening a single Scala file. nvim-metals#67

I'd just like to add upon that that, in the end, what's coming up of current situation is that conforming clients that send null when a workspace can't be inferred¹, will get the server running, but broken, from what I could gather, while other clients, like the referred one in the thread above, will implicit figure out a workspace to appease the server and not the protocol (notice though that for the latter, that could also be a client's issue, it could just not configure a workspace at all and warn/ask users about that).

You have been hit by the nil workspace police 👮🏽‍♂️.

Disclaimer: I'm neither a Metals user or Scala programmer.

¹ : coc.nvim is one client known to do that, and that's the reason it has solved issues with servers scanning the entire home folder because it used to occasionally send ~ as a workspace due to naïve reasoning, like picking a parent's file directory as workspace for example. It now instead follows the spec and sends null when it can't figure a workspace, and most servers are happy with that, by working in "no workspace"-mode. Knowing whether Metals can not work without a workspace will be useful so that coc.nvim should provide their example configuration with requireRootPattern set for this server in specific, so to avoid sending null for it, and making it clear to users that a workspace folder is a precondition for this server to work (though the more conformant would be for servers to accept null and fail gracefully instead of expecting LSP clients being careful at sending null to specific servers).

[ckipp01]

To clarify a couple points and to continue the discussion from the other repo:

will get the server blowing up will get the server running, but broken, from what I could gather

Metals won't blow up. If you open a standalone file and no workspace is sent in, you'll get a warning from Metals telling you that nothing is really going to work. The changes that made this happen are here: #2391

will implicit figure out a workspace to appease the server and not the protocol

Again, this is an explicit decision made my nvin-metals to enable users to have support for standalone Scala files. This has never caused any issues.

coc.nvim is one client known to do that, and that's the reason it has solved issues with servers scanning the entire home folder because it used to occasionally send ~ as a workspace due to naïve reasoning, like picking a parent's file directory as workspace for example. It now instead follows the spec and sends null when it can't figure a workspace, and most servers are happy with that, by working in "no workspace"-mode. Knowing whether Metals can not work without a workspace will be useful so that coc.nvim should provide their example configuration with requireRootPattern set for this server in specific, so to avoid sending null for it, and making it clear to users that a workspace folder is a precondition for this server to work (though the more conformant would be for servers to accept null and fail gracefully instead of expecting LSP clients being careful at sending null to specific servers).

On our side, we'll need to figure out a way to handle this in https://github.com/scalameta/coc-metals since this change will break support for standalone Scala files for coc-metals users. Heads up on this @jsatk.

So to answer your question, no, Metals will not function fully without a workspace. It will result in a None here, warn the user that there is no root, and then not bootstrap the majority of the functionality Metals has to offer.

metals/metals/src/main/scala/scala/meta/internal/metals/MetalsLanguageServer.scala

Lines 320 to 321 in 7d665e7

	case None =>
	languageClient.showMessage(Messages.noRoot)

[oblitum]

Please edit your answer as I've edited mine before you sent yours.

Edit: thanks for the edit.

[oblitum]

Metals won't blow up.

Thanks for the answer's update _{(although, I'd prefer already outdated terms to be left behind as well)}.

If you open a standalone file and no workspace is sent in, you'll get a warning from Metals telling you that nothing is really going to work. The changes that made this happen are here: #2391

will implicit figure out a workspace to appease the server and not the protocol

Again, this is an explicit decision made my nvin-metals to enable users to have support for standalone Scala files.

I noticed that. That's why in my opinion this topic should have been actually resolved in that thread, which got preemptively locked, so, there was no option but ask what's the server's stance here, as you have pointed me to do. Although it's confusing to me what does it mean in that "it's an explicit decision" but an "implicit behavior" (given that it's on its own, "out of the box", picking parent directories as workspace)?

So to answer your question, no, Metals will not function fully without a workspace. It will result in a None here, warn the user that there is no root, and then not bootstrap the majority of the functionality Metals has to offer.

That's correct, and even though it's not providing users with LSP features in such case, it's ultimately following the spec at that. So, in the end, there's nothing to blame the server's implementation here.

[tgodzik]

You have been hit by the nil workspace police 👮🏽‍♂️.

Please refrain from using such a term or giving out warnings if you are not indeed a part of any kind of law enforcement agency. We try to keep the responses and comments positive and helpful to bolster a good community to interact with.

Disclaimer: I'm neither a Metals user or Scala programmer.

If you are not using Metals, why do you need this change? I agree that we should allow to use Metals when no workspace was created, but at the current time we were not able to address the issue and this is not high on the priority list. We would welcome any help or contributions, but otherwise we can only move it to the feature requests repository.

[tgodzik]

In the end it should be solved internally in the server, but until then we will most likely leave the current behaviour of the plugins.

I do understand the concern here, but I think it's more of a benefit than it is danger.

[oblitum]

Okay.

[oblitum]

In the end it should be solved internally in the server

@tgodzik do you think then it's worth opening an issue/feature-request for tracking that? If kept just as discussion it may just get lost or forgotten about with time. Feel free to do so as I'm not currently an user, so possibly not the best person to do that now. I'd subscribe to it though, to eventually learn how things have gone.

[tgodzik]

Raised it here: scalameta/metals-feature-requests#231

It can be voted for and we usually try to pick things from the top of the list.

[oblitum]

@tgodzik thank you.