I started to develop in containers before VSCode introduced the dev container to keep my local machine clean. A few years ago, I switched to the VSCode dev container, and the integration is very good. Having the ability to have a dev environment ready per project is very neat. We started to adopt it in my company. As a team it saves a lot of hassle, and onboarding is much faster. However, we have encountered some issues, mainly when we want to work with GPU and PyTorch dependencies, and that is the opposite of pleasant! Otherwise, now each new project/repo I create comes with a dev container.
Recently went from using devcontainers to nix-shell. But in every new project I include instructions for both nix-shell + direnv as well as dev containers, so people can fully ignore nix if they choose.
A form of this which mixes devcontainer and nix might be the holy grail
Nix sounds like a great fit as well, but my experience with it has not been that great, and I feel it is not ideal for Python. I recently gave Flox a try, which simplifies the use of Nix. I use it from time to time, but it has not yet replaced my development environment.
In your case, is maintaining 2 dev env not annoying?
Yes it is annoying to maintain 2 separate environments, but it's also not my end goal. A perfect solution for me would be a spec that is IDE agnostic, but also works as a VSCode dev container, all from a common source.
Maybe it's an unrealistic goal. But I've actually enjoyed trying and failing with nix so far, so it hasn't been too much of a burden.
We were building something very similar to this in collaboration with the VSCode teams a while back at Meta. The goal was to get development on demand via hooking into some beefy linux server farm shile having VSCode stay as the local experience. Though one of the problems even back then was similar to what you are mentioning. It did however remove all last mile network reliance during lockdown which was a plus.
