"No workspace chosen to import" error on gradle project

[tribbloid]

Describe the bug

this issue can be reproduced by importing https://github.com/acyclic-ai/six-scala on VSCode/Cursor + Scala metals plugin

But the workspace can be seen on the right side

Expected behavior

gradle project should be imported

Operating system

Linux

Editor/Extension

VS Code

Version of Metals

v1.4.1

Extra context or search terms

No response

[tgodzik]

Did you manage to import the build at any point?

I got:

2024.12.16 15:54:27 INFO  Starting a Gradle Daemon, 2 incompatible and 1 stopped Daemons could not be reused, use --status for details
2024.12.16 15:55:18 ERROR 
2024.12.16 15:55:18 ERROR FAILURE: Build failed with an exception.
2024.12.16 15:55:18 ERROR 
2024.12.16 15:55:18 ERROR * Where:
2024.12.16 15:55:18 ERROR Build file '/home/tgodzik/Documents/workspaces/six-scala/build.gradle.kts' line: 12
2024.12.16 15:55:18 ERROR 
2024.12.16 15:55:18 ERROR * What went wrong:
2024.12.16 15:55:18 ERROR Plugin [id: 'ai.acyclic.scala3-conventions'] was not found in any of the following sources:

The issue with no workspace chosen to import is unexpected especially there is only a single workspace

[tgodzik]

I can't reproduce the issue, but looks like we should have a fallback to use the workspace if it's th single one.

[kasiaMarek]

I can't reproduce the issue, but looks like we should have a fallback to use the workspace if it's th single one.

We have a fallback workspace folder instead to handle single files.

The problem is that this project won't be recognised as "metals" project. (People complained that .metals is created in non-Metals project). We search for .scala, .sc, .sbt files in toplevel, and in common paths src/... and */src/.... This project has scala files quite deep... But if you open a .scala file and try to import again it should work.

To fix this: we could assume import-build to be for the focused file (workspace folder in focus) and make this another indicator that this is a Metals project (like for opening .scala file).

[tribbloid]

interesting ... for this particular project I did execute "gradle bloop" before, but it was probably flushed out by git later. Will need to investigate

[tribbloid]

executed gradle bloop and see no difference. This is the only metal I got:

Metals version: 1.4.2
Using coursier located at /home/peng/.local/share/coursier/bin/coursier
Checking Java in JAVA_HOME, which points to /usr/lib/jvm/java-17-openjdk-amd64/
	openjdk version "17.0.13" 2024-10-15
	OpenJDK Runtime Environment (build 17.0.13+11-Ubuntu-2ubuntu122.04)
	OpenJDK 64-Bit Server VM (build 17.0.13+11-Ubuntu-2ubuntu122.04, mixed mode, sharing)
Using Java Home: /usr/lib/jvm/java-17-openjdk-amd64/
2024.12.23 22:19:03 INFO  logging to files /tmp/fallback-service2016220985183771133/.metals/metals.log
2024.12.23 22:19:03 INFO  Started: Metals version 1.4.2 in folders '' for client Visual Studio Code 1.96.2.
2024.12.23 22:19:04 INFO  time: initialize in 1.07s
Initializing Scala Debugger
Release notes was not shown: not showing release notes since they've already been seen for your current version

[kasiaMarek]

executed gradle bloop and see no difference. This is the only metal I got:

That won't help (though probably should). You'd have to create .metals folder or open a .scala file.

[tribbloid]

@kasiaMarek the directory is at the right location.

not sure about .scala files, but theoretically they depends on the first successful workspace compilation (or unsuccesful one on Scala 3), so it's impossible to find them