Authors blog post talking about this project:
If you've already standardized on Docker Compose for development, is there an advantage to migrating to devcontainers?
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.
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.
(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?
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?
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.
Why use one of these premade container images vs using a base image, adding extra packages/layers as needed?
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.