[salamander014]

So, I know very little about this devcontainer spec.

Can I just ask, what value does this spec provide that a simple docker image containing the necessary tools does not already provide?

Why do we need another layer on top? What am I missing?

[owyn]

Well, developers seem to love writing "configuration" rather than "code" these days. But basically a container + the necessary tools IS a devcontainer. It's just a way of automating the "putting in the necessary tools" part especially if you need things that might need to be added to a base container, or services that need to be configured differently based on the external environment that you don't want to bake in for some reason.

If you've ever had to cut and paste a 50 line docker run command snippet but you forgot that one volume mount or port or ENV var that someone added a dependency on last week then you pretty quickly realize just doing complex docker things by hand is a pain. Another example, if you have a script that you want to run to fetch the latest authentication token from a vault after the container launches because you don't want to store it inside the container. Sure, you could write a bash script to run all these steps inside the container after you launch it but it's nice to have a config file to share with another dev and just say: use this.

And the secondary benefit is that having a config file for the editor (like VSCode) so that plugins can manage all of that stuff better. Generally a dev container runs the VSCode Server, and they know how to talk to each other which can make remote development easier. For example, now I can launch the same dev environment locally or on the 56 core xeon 1TB ram server at the office and it's exactly the same as far as the editor is concerned.

It looks like this project is an alternative to the VSCode Server. My team generally uses docker-compose for this since not everyone uses VSCode.

[salamander014]

For the first bit, all I can think is a compose file. Also podman can run k8s configs locally, which I personally hope all of that eventually washes into the same thing. It feels like we already have the tools to make this a "solved" problem, is what I'm trying to say. I just include an additional .env that the compose file pulls in so it's not committed to git.

For the second point, ok this makes a little bit more sense, I've heard of Codespaces or OpenShift Dev Spaces but I guess I still question the value of additional complexity on top of the container (a simple dockerfile in my mind) your vscode instance's terminal is running in.

Thanks for the info.

[bitwize]

It makes it easy to point the tool at a Git repo, have it automagically create a containerized environment for that repo with all its dependencies, and open Visual Studio Code on the codebase inside that remote containerized environment.

Devcontainer was created by Microsoft to support Visual Studio Code's remote development features, so it works best in Visual Studio Code. Inasmuch as other IDEs support it, that's up to the IDE vendor.

[salamander014]

So this is a config standard for the infrastructure underneath something like remote vscode / devcontainers?

[Nextgrid]

One angle is to simplify the setup of what you described. You can do this manually with Docker already, but the DevContainers config means your editor will do it for you.

Another angle is rent-seeking and locking you into a proprietary, expensive ecosystem. Big Tech has successfully convinced most companies to overpay by orders of magnitude for compute and bandwidth, but so far local development machines were excluded. This aims to tackle that shortcoming and make sure you enjoy all the "benefits" of the cloud even during development.

[zamalek]

JSON, everything has to either be YAML or JSON.

If I didn't invent the thing, then we shouldn't use the thing. Dockerfiles fall into this class too, they are just a shitty homegrown DSL.

[rad_gruchalski]

> If I didn't invent the thing, then we shouldn't use the thing.

What about Linux? Or... the internet?