Devcontainers are the principle when development is carried out not on a local machine, but in a special container. Previously, it was quite often virtual machines.
When is it necessary?
- Complex dependencies (usually a bunch of native libraries that are also updated regularly)
- Hardware incompatibility (for example, requires a GPU from Nvidia but developer has Macbooks)
- Weak local machine
- For some reason, it is actively promoted as a means for rapid deployment of projects. But I disagree on this point: usually projects do not require any long deployment, so for most projects it is past.
In other cases, it is still better to completely locally (using different language and package version managers, as well as Docker / Docker Compose).
Now Microsoft is actively developing the initiative as part of its [VS Code](https://code .visualstudio.com/docs/devcontainers/containers ) and [the containers.dev site](https://containers.dev /). The initiative is also supported by JetBrains and their IDE.
What is the difference from Docker / Docker compose? Docker is designed to run, sometimes to build. And devcontainers for absolutely all work: there is nothing locally and is not configured, and all the utilities from the version control system and beyond that are needed for development are in the container. The IDE itself (which is VS Code, which is JetBrains) is half run in a container, and half locally (the so-called fat client, if anyone remembers such a term). The work with utilities takes place either through IDE or through terminal (also built into the IDE).
I tried the devcontainer on a remote machine in PyCharm. It’s a complex project and requires certain Linux libraries and hardware. It’s even surprising that it worked fine (against the background of extremely poor support for remote interpreter via Docker in PyCharm).
So it’s usually not necessary, but if necessary, it’s very convenient.