I am experimenting with dev containers at the moment. I am finding them very useful for setting up environments and they work as advertised. Where I am struggling is the poor support in the Jetbrain's suite and having to accommodate different editors. We need more tooling and editor plurality for dev containers to take off.
Authors blog post talking about this project:<p><a href="https://blog.lohr.dev/launching-dev-containers" rel="nofollow">https://blog.lohr.dev/launching-dev-containers</a>
I wonder if this could be adapted to run vscode, with a devcontainer, but in a sandbox? I want to see and interact with the vscode GUI, and I want vscode to be able interact with the container, but I do not want vscode to have any access to anything else that I don't explicitly grant. This includes my home directory and even my network.<p>One approach might be to try to put vscode into the devcontainer or into another container. But it needs a hole poked for the GUI for for someone to do the plumbing to get the GUI to run in a sandboxed browser context, and I don't think MS makes this easy.<p>(Note that vscode has no security model. If you connect vscode's normal frontend to a malicious backend, you are pwned, and this isn't even considered a bug.)
Can someone describe what it's like to use devcontainers?<p>Is it a last resort, like if your arch is so different from your project environment that you have to go so far as to develop inside a container?<p>I hate even running local docker containers the second I want to do anything inside them. And that's the vibe I get when I read about devcontainers despite wanting to earnestly try it out at one point (I frankly couldn't figure it out back when I tried).
Tooling looks useful, but still trying to understand Dev containers themselves.<p>Why use one of these premade container images vs using a base image, adding extra packages/layers as needed?