Yea when you have tons of python packages to install, VS code containers become real nice. I was new to VS code containers and had a issue trying to debug python inside of it. I wrote an article for anyone who might be having the same issue. https://python.plainenglish.io/python-debugging-within-visua...
1. Team onboarding is almost zero effort. I spent upwards of a week onboarding in the past (install this library, install this server, install is broken, try again, etc.). That becomes clone, click, and forget with dev-containers.
2. If you CI you dev-container and publish to a private registry, only one computer is spending the time installing and setting up dependencies. Everyone else simply bases their local image off of that one (and saving productive working time).
3. If you mess up the dev environment with some failed experiment, simply recreate the container and carry on.
4. The dockerfile is a form of documentation: what is needed for this thing to run.
5. If you use Github, you can run your environment in a browser if you are in a pinch. I've only done this once, but it was hella useful.
vanillax|4 years ago
danieka|4 years ago
zamalek|4 years ago
2. If you CI you dev-container and publish to a private registry, only one computer is spending the time installing and setting up dependencies. Everyone else simply bases their local image off of that one (and saving productive working time).
3. If you mess up the dev environment with some failed experiment, simply recreate the container and carry on.
4. The dockerfile is a form of documentation: what is needed for this thing to run.
5. If you use Github, you can run your environment in a browser if you are in a pinch. I've only done this once, but it was hella useful.
unknown|4 years ago
[deleted]
arcbyte|4 years ago
dzonga|4 years ago