3 ms·
for sure. i do most of my work in Golang, which uses a system wide package store, and I hated that about it... until i discovered the Visual Studio Code remote
by ohthehugemanate 5y ago
for sure. i do most of my work in Golang, which uses a system wide package store, and I hated that about it... until i discovered the Visual Studio Code remote container extension. It lets you define a container environment for your application - probably the same container you already use for CI - and it splits vscode into a thin client and a "server" running in your container. meaning: a dedicated local environment for each project that's fast to spin up and identical to CI.
My projects are self contained again, even though they use global package stores, and my IDE can treat the package store dir as a part of the codebase for debugging. I love it.
- config_yml 5y agoTIL, thank you so much. I'm going to try this today for our project setup.
- arp242 5y agoYou can use "go mod vendor" to achieve the same, no?
- ohthehugemanate 5y agoI think so, but then you lose the other benefits of an isolated, totally reproducible environment that all your devs use.
- arp242 5y agoOkay, but that's a bit of a different thing; was just commenting on the "treat the package store dir as a part of the codebase". That being said, overall I found all of that more trouble than it's worth btw, certainly for Go. I certainly had to debug and fix far more issues with the container software itself than with issues derived from diverging environment issues, especially on coworkers machines who aren't very familiar with all of this and are "only" developers (nothing wrong with that btw).