Ability to specificy extension versions in .devcontainer.json

[lawrencegripper]

Devcontainers provide a nice way to ensure all on the team have the same environment. The team I'm in has been using them lots and loves them. We've pinned our dependencies in the dockerfile to ensure all devs have the same environment.

One remaining non-deterministic behavior is around the extensions installed. Depending on when the dev builds the container they'll get the latest version of the extensions listed. It would be great to pin these with control to say "take minor releases but not major". This would prevent team members having different version of the extensions and seeing different behavior based on when they build their devcontainer.

Most notably this hurt us when mscode.golang move to golang.go cause confusion - our aim was by pinning dependency versions our devcontainers wouldn't rot and we could pickup older projects easily, this broke that expectation a bit. Other instances have seen newer versions of extensions change behavior or their settings paths.

Ideally we'd like track extensions along with their version in .devcontainer.json. It would hopefully solve things like name changes and settings updates by removing the chance of two people in the team seeing different behavior as they're on different versions of an extension:

	// Add the IDs of extensions you want installed when the container is created in the array below.
	"extensions": [
		{ name: "golang.go", version: "~1.2"}
	]

Originally discussed here: microsoft/vscode-dev-containers#375 (comment)

[Chuxel]

//cc: @sandy081 @chrmarti

[WhisperingChaos]

Although one can execute code within the running code's terminal, the --help doesn't list the option '--install-extensions'. Also, an attempt to use code --install-extensions <ExtensionPackage.vsix> fails with a message similar to option not supported. I'm sure this behavior is by design, however, if this code option were available one could use a Dockerfile to include all the required <ExtensionPackage.vsix> in the resultant image then use code to install them when running the container.

In general, for complex projects, I will include the development tooling, such as code and the extensions required to edit and build the project's artifacts in the project's git repository. This tooling is configured and constructed via a Dockerfile derived from a ubuntu image. Therefore, the only required dependencies a developer need provide to further evolve a project are a Linux distro with x11 support and an installed, compatible docker daemon. The project's build process constructs an image that includes code in its file system and will start it when this image is run. This works within a Linux host environment running X11 enabling code's GUI to present itself as just another window on the host's desktop even though it's running within a container. I prefer this arrangement, as all the project's tooling remains encapsulated in the running container, including code, avoiding the pollution of the host's environment.

At the time of this post, although Microsoft has indicated it will support Linux GUI apps via WSL2, this enhancement is unavailable via the stable version of WSL2. Since, without this enhancement, Windows would require the installation of other third party components to enable running code within a Linux container and I must develop a solution using a Windows host, I'd like this remote extension to install the specific versions of code extensions required to complete the development container's configuration, however, the develpment of this enhancement isn't pressing for me. Essentially, once WSL2 supports Linux GUI apps, I won't need the remote extension offered by this repo, let alone the version spec enhancement to the devcontainer.json extensions array.

[Chuxel]

@WhisperingChaos This is a bit off topic for this issue. Please raise your own if you have a feature request. This feature request is around specifying a version of an extension in devcontainer.json. Thanks!

[chrmarti]

The VS Code CLI does not support installing specific versions of extensions if I remember correctly.

[WhisperingChaos]

@Chuxel
I disagree with the characterization that my previous post "is bit off topic for this issue". To summarize my response below

• I'm not asking for another feature.
• I would suggest considering the problem before implementing a specific solution.
• I'm providing suggestions to circumvent the problem until it's addressed.

The mention of the --install-extension option suggests a possible workaround for individuals that seek installing a specific extension version within a container. Unfortunately it doesn't work in this context. Therefore, I'm attempting to conserve other developer's time in their effort to circumvent this issue, by eliminating this non-functioning workaround. Also, I unfamiliar with this remote extension and I'm not fully confident that the --install-extension option shouldn't be supported. Therefore, its mention allows others, with in depth knowledge of this remote extension, to potentially notice this possibly abnormal behavior and take appropriate action.

This topic focuses on a solution to the problem: "How to ensure installing specific versions of code extensions within a development container". Focusing on a specific solution instead of considering the problem can increase the complexity of a product from an end user's perspective. A product complected by focused/point solutions requires the user to intimately understand the context each solution is engineered to address so a user can apply the particular point solution. Instead, one would hope various point solutions could be avoided through abstraction so a user could, in a declarative manner, specify the desired outcome without having to apply changes to various configuration files in order to achieve the desired result. For example, it might be an improvement to specify: ensure extension "x" version "V1" is locally installed. where the abstraction of locality is remapped to a running container by this remote extension, instead of requiring an end user to identify and change the proper settings in one or possibly more configuration files.

The second and third paragraphs provide insight to other current and near future solutions that would allow developers to circumvent this issue for specific environments. These solutions may be important to other developers, as there is currently no commitment that this issue will be addressed by a pull request nor a time frame specified for its deployment.

[WhisperingChaos]

@chrmarti
Although the --install-extension option doesn't explicitly support specifying a specific version number, the .vsix files downloaded from the VScode extension marketplace are, for the ones I've downloaded, suffixed by one. Of course one would have to install an extension to verify that the .vsix package contains the desired version. Regardless, I believe we can agree that a .vsix package represents a snapshot of the extension at the time it was taken. Therefore, it can be used to ensure an extension reflects a desired state.

[lawrencegripper]

The VS Code CLI does not support installing specific versions of extensions if I remember correctly.

If I can remove this limitation would you consider the change? @chrmarti

[sandy081]

The VS Code CLI does not support installing specific versions of extensions if I remember correctly.

@chrmarti VS Code does support it - microsoft/vscode#12764

code --install-extension abc.def@1.2.3

But the limitation is microsoft/vscode#63903 - If auto updates are enabled VS Code automatically installs latest version in this case.

[WhisperingChaos]

Seems this feature request has already been partially implemented. I applied the version specification @Major_NN.Minor_NN.Point_NN as illustrated by sandy081's post for CLI. Although the parser for devcontainer.json indicated, through highlighting and a message, that the added version specification was invalid for the versioned entry in the extensions array, the rebuild completed successfully by incorporating the desired prior version of the specified extension into the container.

Here's example json that worked:

// Add the IDs of extensions you want installed when the container is created.
"extensions": ["github.github-vscode-theme@1.1.2"]

Specifying @1.1.1 was also successful.

// Add the IDs of extensions you want installed when the container is created.
"extensions": ["github.github-vscode-theme@1.1.1"]

Please note, the current version of github.github-vscode-theme is 1.1.3, and as sandy081's post mentioned, automatic updates to extensions must be disabled to prevent code from upgrading extensions to the latest release.

My version of code is 1.46.1.

[PavelSosin-320]

Maybe, it is completely out of context but in the Cloud application development cycle, the new version is rolled out to customers via publishing a new version of application/component to the docker registry used by application users, and the registry triggers the rolling update of the entire application stack. All this mechanism is already integrated into the Docker technology stack. Docker images have no version, they are tagged! And the tag is not the version. The exact version of the software installed inside the container image is not interesting to anybody except the image developer. If the container provides some service it doesn't matter which software version is used unless API/CLI is changed or extended. Git always does git, Make always does make, Node always does nodejs.
Automatic update of applications today is the only acceptable mode of application usage to ensure application availability.

[chrmarti]

Fixing the validation to allow for version numbers. Remaining work is tracked with microsoft/vscode#63903.

[lawrencegripper]

@chrmarti would you be open to keeping this issue open? Specifying a specific version of an extension only to have VSCode immediately auto update it doesn't feel like the behavior a user would expect.

I tried out a .devcontainer.json which looks like the following. This resulted in the newer version 0.15 being installed immediately.

	"settings": {
		"extensions.autoUpdate": "false",
		"extensions.autoCheckUpdates": false,

	},
	"extensions": [
		"golang.go@0.14.4"
	]

To resolve this I am considering if code in general would benefit from the ability to pin a version for a specific extension from the CLI. This issue suggests that there is a mechanism in code which holds a version pinned while allowing others to update. If I dig out how this works can we use it? cc: @sandy081

I was thinking it would do as follows:

cmd	result
code --install-extension extension@version	Version Installed. Extension not updated by auto-update
code --install-extension extension	Latest Installed. Updated by auto-update

Alternatively would it be ok for me to look at detecting when a devcontainer is running with specific version in the extensions block and disabling the auto update feature?

[chrmarti]

@lawrencegripper My current understanding is that only a fix to microsoft/vscode#63903 is missing, you might want to join the discussion on that. I have closed the issue here because I don't expect additional changes to the Remote-Containers extension for this.

[lawrencegripper]

Ah ok got it sorry was being slow, it's still broken but the issue is closed as this isn't something specific to devcontainers any more.

Once microsoft/vscode#63903 is resolved things will play nice.