Support of having multiple .devcontainer configs

[andyli]

My use case is to help develop a library against multiple language versions.

Let say I have a Python library that supports both Python 2 and 3. I want to be able to choose the Python version when opening the folder in container.

[bamurtaugh]

We have support for VARIANT, which would allow you to use different versions of Python:

You could update the VARIANT to a certain version of Python, then select Remote-Containers: Rebuild Container, and the container will update to the specified version.

[bamurtaugh]

Closing #2143 in favor of this one for housekeeping and as they request the same overarching feature for multiple configurations.

To summarize #2143:

• Support multiple configurations in devcontainer.json and allow the user to pick which one to run. Similar to the request in OS specific dev containers #2067 but more generic instead of OS-specific only.
• When multiple definitions are found, selecting re-open in container should then prompt you to pick one of the container definitions. This would help with developing/testing/debugging code on different versions of linux (not all products are deployed in docker).
• If a docker.host field can also be added to the config, it would also be great for developing code for embedded platforms like a tegra. The code can be developed on a desktop, and then you can switch to the aarch64 container and run it in that container over SSH on the actual hardware. Currently to do that you need to replace your devcontainer and enter the IP in settings.json.
• A frequent use case for multiple containers Is generally GPU/CPU separate images.

[bhack]

How this will fit with the multiarch case?
https://github.com/multiarch/qemu-user-static

[bhack]

Also for build/rebuild action we need to control platform flag https://www.docker.com/blog/multi-platform-docker-builds/

[PavelSosin-320]

The correct solution forever was proposed by one of GoF members by separating template and parameters into 2 separate files. The template defines tasks, i.e. common sequence of steps with parameters placeholder, like Gist. Values file is a small property self-explaining file. They are merged into one executable script using a very simple framework like Mustache before running by a scripting engine, like bash or wsl bash.
Such kind of solution servers Kubernetes Cloud developers already many years in the form of Helm. It provides unlimited flexibility and the free exchange of code between developers. The only dependency is Internet access, like for GitHub and DockerHub.

[grigorig]

I don't understand why this has to be so complicated or needs to cater to special use cases (e.g. automatic detection of configuration based on OS/architecture). Just allow us to have several devcontainer configurations and allow us to pick one when the project is opened in a container. That's good enough for most use cases.

This could be as simple as having several JSON files in .devcontainer/. VSCode would just need to discover the configurations and ask the user to pick one.

[alex1234567890123456789]

This would be incredibly useful for my group. We do ALL development in docker containers.

As @bamurtaugh mentioned already, having a config for an aarch64 image so you can develop/debug on a Tegra over ssh is a critical use case.

We also sometimes have to test/release software on other OSs, so having a ubuntu 18.04 image and a ubuntu 20.04 image and a centos 7 image that you can switch between makes that a snap. Yes you can have a script that builds for all targets but if you actually run into a bug and want to debug within the IDE you need to have the right devcontainer.

Another use case is for monorepos where you have several project components that are quite distinct - think a server component and a desktop component. With multiple devcontainers you can easily switch between developing/debugging the server part or the desktop part.

I don't think this needs to be super complicated. Either scan for multiple json files in the .devcontainer directory, or allow devcontainer.json to contain an array of definitions. The "reopen in container" option can pop up a list of all container definitions when there is more than one (same with the "rebuild container" option etc). The container definition already has a name which shows up in the status bar... it feels like it was designed with multiple devcontainers in mind.

Another great feature to go with this would be to add a boolean "local" option in the container definition. If that's set to false it would prompt you for a docker context to use. This would let you switch between running local devcontainer images and running one on a tegra or server without having to manually switch contexts and restart vscode.

[baruchiro]

I think I can handle it, if a member of this project will direct me.

I just need to know where is the function that searches the .devcontainer files, and how to dialog with the user.

(I can do that myself of course, but it requires more time, and I'm not sure I have it.)

[ringgelerch]

This feature would also be pretty useful for me and my team. We develop applications for embedded system. In this scenario we build the application for different operating systems (Mac, Linux, Windows) and hardware platforms (x86, arm). As mentioned by @alex1234567890123456789, it would be great to be able to define multiple devcontainers, one for each OS/HW combination. The correct container could be chosen inside the "Reopen in Container" dialog.

Development Containers are a huge benefit in cross-platform development and I'm really impressed with the implementation in VSCode and the Remote-Container extension. This feature would make it much easier to keep DevContainers clean and switch the development environments with a few clicks.

Are there any plans to put this feature-request into action?

[pbiggar]

This would be useful as I have a remote docker host, and the settings for a remote docker host differ slightly from a non-remote docker host (in particular, the workspaceMount needs to absolute directory of the checkout on the remote host, but also the consistency is different and I have to disable a number of mounts. A good way to solve this would be by having a .devcontainer.json and a .devcontainer.remote.json and letting me choose when I choose to use a remote container.

[chrmarti]

This has become available as a stable release in Dev Containers 0.275.0. See https://code.visualstudio.com/remote/advancedcontainers/configure-separate-containers for documentation.