I work on a team of software engineers who support a suite of Python services. We use docker orchestrate those services in development. For example, I might edit code in one service, and when I save a change, the changes are reflected in the relevant container via a bind mount, then the service gets inotify’d of the change and hot-reloads. The configuration for these docker containers are checked into git and shared across the team. This way, none of the engineers are required to install Python or any of the required packages on their workstations, and we can be sure that the environment in which software is built closely mirrors production.
It appears that VsCode does not support this approach to development gracefully. Since none of the dependencies are installed on engineers’ workstations, the Python extension shows tons of false-positive import errors. We can’t make use of linting, and we can’t use VsCode’s debugging or build features.
At first glance, it would appear that VsCode Remote is intended to solve these problems, but upon closer inspection, it creates a whole suite of new problems. Since many extensions have to be installed inside the container, engineers either lose the ability to customize their editors or must reconfigure their editors every time a container is restarted. The docs suggest using a volume to persist the configs, but there doesn’t appear to be any way to sync them to or from a local directory. There appears to be no support for a codebase that produces multiple containers. And finally, using the Remote pack would require us to add special VsCode-related config to our shared dockerfiles, and some of the members of the team use other editors. In short, it turns an individual concern (editor configuration) into a team concern.
Am I missing something here? Is there any supported way to work in a containerized development environment with VsCode when the container configurations are maintained as a team? I feel like I can’t be the only person who has this problem.