spec
spec copied to clipboard
devcontainers
Proposal: Allow using env-vars in devcontainer-feature.json
My current use case involves defining additional container mounts in the future users home directory in the container. It seems to be impossible at the moment, since the remoteUser is configurable.
${devcontainerId} seems to be the only variable that can be used in the devcontainer-feature.json file. There are 2 env variables mentioned in the feature spec (_REMOTE_USER_HOME and _CONTAINER_USER_HOME) but they are only accessible in the install.sh-script.
I'd like to have access to more variables, either the ones passed to the install-script, or the ones used in the parents devcontainer.json.
Hi 👋
I agree, it would be helpful if we could make environment variables passed to the devcontainer.json and added as Feature options available to devcontainer-feature.json.
Our current set of dev container Features would benefit from this as well, we have https://github.com/devcontainers/cli/issues/391 opened which tries to tackle another such scenario.
Hello there, once again... can I do something to get this going? I'd love to finish some devcontainer features but they depend on these variables...
Hi 👋
We currently have this issue in our backlog, @bamurtaugh @joshspicer looking for your thoughts on this one.
I agree this one sounds useful, thanks for opening @max06!
Since this is an open spec, we really value feedback and contributions too. @samruddhikhandale @chrmarti would you find it reasonable to suggest anyone from the community could also contribute this request via PR to https://github.com/devcontainers/cli? If so, then @max06 you'd be able to kick this off directly!
Looks like I overestimated my abilities here 🙈 (Any help/hint would be greatly appreciated!)
Adding another use case here, would be great to be able to use ${localEnv:HOME}${localEnv:USERPROFILE} for the mounts in features. I'm working on a feature to allow adding Python packages using a requirements.txt and it would be great to be able to give users the options to use a requirements.txt that's store on their host rather than in the container. Don't see a way to accomplish this otherwise.
