3 ms·
I spent more than a year living with the numerous downsides of high level CDE (containerized development environment) tools. I must admit that I am very skeptic
by theK 3y ago
I spent more than a year living with the numerous downsides of high level CDE (containerized development environment) tools. I must admit that I am very skeptical about all options available right now and that I have rolled back to using plain, old school, docker compose based CDE.
Both .devcontainers and .devfile managed to create more effort than they took away. Some key points:
- long lived containers
- abstracting away the fact that you run stuff inside containers in the IDE and abstracting away the container life cycle
- cryptic error states and error messages, especially when setting up new projects from scratch. This often boiled down to bad plugins (even Microsoft's own VSCode plugins wet the bed often)
- only superficial support for podman
- bad support for arm based HW (and arch translation issues, like a tool requesting arm containers but the host running docker is x64)
At this point I consult teams to try out a plain compose.yml as a CDE and skip the "enterprise" stuff.
- WhatIsDukkha 3y agoThis seems to be podman focused from what I see.
- theK 3y agoNo, not really. A big part of the problem is half baked software on the client side. For devcontainers even the reference implementation CLI is significantly incomplete.
- WhatIsDukkha 3y agohttps://happihacking.com/blog/posts/2023/dev-containers-emacs/ https://happihacking.com/blog/posts/2023/dev-containers-emac... Looks pretty useable to me...
- theK 3y agoYou still cannot stop, remove or update a Dev container from CLI and there at numerous issues with the rest of the implemented features. [0]: https://github.com/devcontainers/cli?tab=readme-ov-file#context https://github.com/devcontainers/cli?tab=readme-ov-file#cont...