RFC support reading dotenv files in tasks and plugin/workspace configuration

[TobiG77]

Explore loading environment variables from dotenv files as single source of truth for secret configuration settings that should not be part of the git repository and in as few places as possible.

This is a first draft and 'works on my machine' but I am looking for feedback regarding maintainability or other use cases I may not be considering.

Enables loading a dotenv file via i.e. workspace config:

{
	"folders": [
		{
			"path": "."
		}
	],
	"settings": {
		"elixirLS.projectDir": "myProjectDir",
		"elixirLS.envFile": ".env"
	}
}

or in tasks:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "mix_task",
            "name": "mix (Default task)",
            "request": "launch",
            "projectDir": "${workspaceRoot}/myProject/",
            "envFile": "${workspaceRoot}/.env"
        },
        {
            "type": "mix_task",
            "name": "mix test",
            "request": "launch",
            "task": "test",
            "taskArgs": [
                "--trace"
            ],
            "startApps": true,
            "projectDir": "${workspaceRoot}/myProject/",
            "envFile": "${workspaceFolder}/.env",
            "requireFiles": [
                "test/**/test_helper.exs",
                "test/**/*_test.exs"
            ]
        }
    ]
}

I verified the behavior with a test project and modifying test_helper.exs

System.get_env |> Enum.each(fn {n,v} -> IO.puts("name : #{n}\nvalue: #{v}") end)

ExUnit.start()

The current implementation has a few potential weaknesses / gotchas, which in my opinion is sufficient to address via documentation

1. little control out of the box within the app / code over what env vars are actually imported, though one could argue that this may not be desirable / out of scope and should be handled in the app consuming the environment variables
2. given a workspace configuration already had a envFile and an alternative envFile is specified , environment variables loaded in the previous file will not be removed from the environment - in the debugger a simple restart suffixes to clear the old environment variables

[TobiG77]

Hi,

Thanks for the feedback. I share your concerns. I'll see what I can come up with based on your feedback.

Cheers

[lukaszsamson]

@TobiG77 are you still interested in getting this merged? It doesn't seem to be a highly asked for feature and I don't really see the use cases

[lukaszsamson]

Closing as OP is not interested anymore and no compelling use cases has came up.