search

microsoft / vscode-dev-containers

NOTE: Most of the contents of this repository have been migrated to the new devcontainers GitHub org (https://github.com/devcontainers). See https://github.com/devcontainers/template-starter and https://github.com/devcontainers/feature-starter for information on creating your own!
https://aka.ms/vscode-remote
MIT License
4.72k stars 1.4k forks source link

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

Open markus-geiger opened 2 years ago

markus-geiger commented 2 years ago

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

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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!