Scala development with dockerized [jupyter notebook -> jupyter-lsp -> metals -> bloop -> maven]

[stanton-scott]

Hello, I am currently trying to get this setup to work and wanted to check if it is possible first:

Within a Docker container:

• workspace directory: /home/jovyan/notebooks/
• I have jupyter notebook running with jupyterlab-lsp connected to metals (Language server visible in jupyter frontend)
• A Scala compatible kernel is installed
• Metals logging and trace logging is enabled and working
• I installed and started my own instance of bloop because the instance started automatically by metals is hard to observe
• a maven build with abstracted Scala code is exported to bloop using maven and a pom.xml during docker build
• a .bloop directory exists with a <project>.json and <project-test>.json visible
• running bloop projects shows that <project> and <project-test> are present

Code:

• glue-interactive.zip
• pom and notebook are stubbed to represent the structure but are not valid

Current issue:

When I open a notebook, jupyterlab-lsp creates a .virtual_documents folder and sends the location /home/jovyan/notebooks/virtual_documents to metals in the initialization request. Metals then logs the following under /home/jovyan/notebooks/.virtual_documents/.metals

2025.02.17 11:42:08 INFO  Started: Metals version 0.11.2 in workspace '/home/jovyan/notebooks/.virtual_documents' .
2025.02.17 11:42:08 INFO  Parse release: 17.0.14
2025.02.17 11:42:09 INFO  time: initialize in 0.91s
2025.02.17 11:42:09 WARN  Build server is not auto-connectable.
2025.02.17 11:42:09 WARN  no build tool detected in workspace '/home/jovyan/notebooks/.virtual_documents'. 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. 

Questions:

• Is this setup possible?
• I don't think it is possible to store any .bloop or maven data under .virtual_documents as it is cleared on initialization, and changing the location of .virtual_documents probably wont help either.
• Is it possible to influence the initialization request from jupyterlab-lsp to start metals under notebooks/ where my .bloop and pom.xml exist, while still enabling the features of the language server for my notebooks?
• Am I missing or misunderstanding something in my setup?
• If I solve the issue with .virtual_documents, is it possible to connect metals to the manually started bloop server via cli?

[tgodzik]

Related topic scalameta/metals-feature-requests#236

Maybe you can set metals.customProjectRoot to the parent of .virtual_documents ? Just ..?

[stanton-scott]

As we want to use AWS Glue features we will currently be bound to Scala 2.12 (org.scalameta:metals_2.12:0.11.2). From a quick look I don't think that customProjectRoot existed at the time.

[tgodzik]

Metlas Scala version should not be relevant to the project scala 🤔 since it's a totally separate JVM.

[stanton-scott]

Thanks for your support. I have upgraded to the latest version.

I am configuring the language server via jupyter_notebook_config.py, is this the correct way to set metals.customProjectRoot?
I have also tried with "serverSettings": ... but either way I am not able to correctly configure it.

It is not that clear where to set these properties from user-configuration docs, or other documents that I have checked.

c.LanguageServerManager.language_servers = {
    "metals": {
        "version": 2,
        "argv": ["/usr/local/bin/metals"],
        "languages": ["scala"],
        "mime_types": ["text/x-scala", "text/x-scala-source"],
        "display_name": "Scala (Metals)",
        "initializationOptions": {
            "metals.customProjectRoot": "/home/jovyan/notebooks"
        }
    }
}

When I start the container the following is logged:

2025.02.17 16:12:37 INFO logging to files /tmp/fallback-service1026474116092553735/.metals/metals.log

and when I open a notebook:

2025.02.17 16:12:37 INFO Started: Metals version 1.5.1 in folders '' .

[tgodzik]

That should be a relative path, so .. should work, but not absolute one.

I guess you took the example from https://jupyterlab-lsp.readthedocs.io/en/latest/Configuring.html#example-scala-language-server-metals-integration ? Looks like maybe it should go to workspace_configuration according to the schema