Environment variable handling with metals debugger interation

[mweisshaupt1988]

Hi, I'm experimenting with automatically loaded configurations and environment variables once a language server has been initialized. While I have this working wonderfully for C++ I do not get it working with Scala.

It would be cool if I could do project configuration like this because our Scala programs run in docker containers which utilize environment variables. But I do not want to clutter my neovim configuration with dozens of variables and debug configurations and this approach would allow me to check in the configuration for other colleagues to use as well.

Consider the following (partial) metals configuration:

metals_config.on_attach = function(client, bufnr)
    require("metals").setup_dap()

    local projectconf = io.open("projectconf.lua", "r")
    if projectconf ~= nil then
        io.close(projectconf)

        require("projectconf")
    end
end

Example projectconf.lua:

vim.env.ENV_1 = "Hello World"
vim.env.ENV_2 = "This is rather cool."
vim.env.ENV_3 = "I wonder if it is possible to get a env variable from a password manager..."

require("dap").configurations.scala = {
    {
        type = "scala",
        request = "launch",
        name = "Run or Test Testprojekt",
        metals = { runType = "runOrTestFile", },
    },
}

And finally a simple Scala program:

object Main extends App {
  println("Reading directly from env...")

  val env = System.getenv()
  println(env.get("ENV_1"))
  println(env.get("ENV_2"))
  println(env.get("ENV_3"))
}

This works perfectly if I run it in a neovim terminal window with "sbt run" but it does not work with the dap integration. There the environment variables are not set!

My investigation revealed that indeed starting a debug session does not set the environment variables although a new jvm process is started for the debugee. Also setting environment variables via the configuration keys mentioned in the metals documentation does not work that way because it will only be loaded if the configuration happened before initializing the metals server. I'm suspecting that the environment variables present while metals was started are passed to the debugee but the newly set variables are not seen by the new process.

Edit: Manually restarting the metals server indeed fixes the issue but this is not a nice workflow :D

Does someone have an idea how to proceed here? Is there some way of forcing metals to read the environment on starting the debugger or something similar?

[antosha417]

I have this in my dap configuration:

dap.configurations.scala = {
  {
    type = "scala",
    request = "launch",
    name = "Run or Test Target",
    metals = {
      runType = "runOrTestFile",
      envFile = ".env",
    },
  },
}

Example of .env file would be:

ENV_1="Hello World"
ENV_2="This is rather cool."
ENV_3="I wonder if it is possible to get a env variable from a password manager..."

If I need to run project form sbt I use a little alias alias e='env $(cat .env | grep -v "#" | xargs)' and do

e sbt run 

You can also take a look at https://direnv.net/

Also be careful and don't push this .env file to public repositories if it contains sensitive data. I use global git ignore file for that.

[ckipp01]

Yup this is pretty much exactly what I was going to mention that it'd be a good idea to maybe just stick these in a .env file and set envFile to point to it and it should pick that up on very run.

[antosha417]

This is not related to your question, sorry for the off-topic. But just wanted to mention that if you want per project configuration it may be dangerous to jut run everything in projectconf.lua since some random repo form internet may have malicious code in projectconf.lua. Usually plugins for project specific settings ask for some file authorization every time file content is changed.
You can take a look at this plugin or any other plugin for ideas of how to implement it if you want.