Introduce ${dotEnv:VAR_NAME} to .devcontainer.json

[markus-geiger]

Could you introduce something like ${dotEnv:VAR_NAME} to variable substation .devcontainer.json?

That would allow us to keep project/developer-specific information in one or more .env file like image-name or other settings (like mounts points on developer host systems like for private keys) that are also used in other files.

I would suggest adding "dotEnvFiles" : [".env-defaults", ".env"] so we can have defaults. The later file overwrites the vars from the preceding one.

Additonally

• dotEnvStopOnMissing: bool could throw an error if one file is missing, otherwise just skip.
• dotEnvStopOnError: bool could throw an error of parsing failed or dotEnvStopOnMissing == true.

dotEnvFiles would be read before actually any other keys in devcontainer.json so they can be used in value expressions. No preprocessing of value strings. Meaning I would not allow putting ${localEnv:HOME} in .env files to keep things simple.

https://code.visualstudio.com/docs/remote/devcontainerjson-reference#_variables-in-devcontainerjson

[markus-geiger]

Using other extensions like https://github.com/direnv/direnv-vscode is not seen as option since like for that enforcing dotenvto be installed on host system is nothing we want to do. Also we want to use well only well maintained and trusted extensions. And that extension would already be needed on host system VSCode.

I see a meta.env and copyLibraryScriptsForAllDefinitions in https://github.com/microsoft/vscode-dev-containers/blob/bd53a6615fa12ccb8fade3426b9c0ff0fbfce317/build/src/prep.js . Currently looking at it and how it is used. UPDATE: okay, it's just used for "features" option. Too late in lifecycle…

[markus-geiger]

Only workaround imaginable would be to run initializeCommand and use a a local hard-coded image name for the container image. Still the problem isn't solved and would open some other glitches.

[bamurtaugh]

Hi @markus-geiger, thanks for opening.

We are making dev containers an open specification (info), and I think this type of request would be fitting for the spec repo: https://github.com/devcontainers/spec/issues. Please let me know if this makes sense to you as well, and if so, we can close out this issue if you open one over there. Thanks!