Mill build-related files aren't recognized as build files

[ckipp01]

Describe the bug

So I'm reporting this as a bug instead of a feature requests because when you hit on this it has the possibility to really screw up your workspace. When working in a Mill project that has project/*.sc files like scala-cli has, if you change anything in these files you constantly see the following:

Even if you choose Dismiss and make another change you will again get prompted for the same thing on every single save. If you end up accidentally selecting one you also confuse metals and end up creating extra dirs like a .scala-build in the project dir when that's not what you actually want which can end up really confusing the user.

Expected behavior

I'd expect a prompt to import the build instead of this prompt. Even better would be a way to tell Metals not to keep asking this constantly.

Operating system

macOS

Editor/Extension

Nvim (nvim-metals)

Version of Metals

0.11.12+195-c2642c63-SNAPSHOT

Extra context or search terms

No response

[tgodzik]

The problem is that it's hard to recognise is something is actually a mill build file since there is no convention here unless I am mistaken. People can use any kind of directories. We could turn off scripts in mill projects, but then you wouldn't be able to use them.

For sure we should not reask after dismissing, which I thought is already the case :thinking:

[ckipp01]

For sure we should not reask after dismissing, which I thought is already the case 🤔

Yea I think the "Dismiss" and "Don't ask again" has different behaviors. Maybe we should also offer a "Don't ask again" here.

Related to this is https://github.com/build-server-protocol/build-server-protocol/discussions/502 brought up by @lefou. Either way, right now I think the behavior is really quite confusing.

[jkciesluk]

Are you still asked to re-import build after changing something in this file, or there is only message about importing script?

[ckipp01]

Are you still asked to re-import build after changing something in this file, or there is only message about importing script?

You are asked, but if you save multiple times in a row, you'll get the one that I showed. So it's like there is some sort of recognition there that you should reload, but you still get prompted to import it as a script as well.

[lefou]

I think Mill explicitly marks paths (files and dirs) which belong to a module, in this case the mill-build module, which represents the Mill project itself. Maybe, it's a good idea to not ask for files which are already known to be part of a source set of a module and only ask the user in case a file is not already associated so some tool chain.

[kasiaMarek]

I think Mill explicitly marks paths (files and dirs) which belong to a module, in this case the mill-build module, which represents the Mill project itself. Maybe, it's a good idea to not ask for files which are already known to be part of a source set of a module and only ask the user in case a file is not already associated so some tool chain.

I don't think metals would suggest importing as scala-cli script for files that already belong to a build target. So this shouldn't be an issue with mill as a build server. It would be present in bloop, since mill-build target is not imported to the bloop config (I think). Adding support for mill-build target should also fix this issue, do we have some plans relating to that?

[lefou]

AFAIK, the mill-bloop contrib module has currently no maintainer. But we ensure the code compiles and the existing tests succeed.