support extensionKind ui and workspace

[leighmcculloch]

What

Indicate to VSCode that the extension can run in ui mode or in workspace mode.

Why

When using VSCode with remote containers support VSCode can run extensions locally where the UI is being displayed or remotely where the files live. Many extension can run in either location, although some extension can only run on the ui side and some can only run on the workspace side.

When an extension doesn't indicate where it can be run it always runs at the workspace side.

The docker extension can run either on the UI or on the workspace and I think it should really be up to the user to choose. The advantage of changing this and indicating it can run in both places is that when using remote dev containers the developer doesn't have to manually install the extension in the container to use it to control their local docker setup.

[bwateratmsft]

We intentionally removed the extensionKind specification in #2422. The motivation was that even with workspace first in the list, in remote sessions it would default to using ui mode, which is almost never what users actually want. It resulted in quite a bit of user confusion. By removing the extensionKind specification, it requires users to install the Docker extension in the remote context (i.e., use workspace mode), unless they have specified the following setting:

    "remote.extensionKind": {
        "ms-azuretools.vscode-docker": [
            "ui"
        ]
    }

For the relatively few users that do actually want it to use UI mode, we felt this was a satisfactory workaround.

[leighmcculloch]

@bwateratmsft Thanks for explaining.

in remote sessions it would default to using ui mode, which is almost never what users actually want.

Could you elaborate on this? Are you referring to remote SSH or remote containers or both?

[bwateratmsft]

Both, along with Codespaces and WSL as well. Most commonly the issues/confusion would occur in SSH/Codespaces/WSL, though (not often you would have Docker in Docker in a remote container scenario).

If the user is only editing Dockerfiles--and not using the explorer, commands, tasks, other features--then UI mode is sufficient. However it seems like most people using remote sessions are using those other features, and in UI mode, if Docker context or DOCKER_HOST are unset (or in general, set to something other than the target remote machine), then the explorer would be showing stuff from the wrong place. For example, if I have a remote SSH session to ssh://foo@bar.baz, but my Docker context is just my dev machine, then in UI mode the Docker explorer would be showing Docker resources from my dev machine--not from ssh://foo@bar.baz.

[karolz-ms]

@leighmcculloch if you read the description of "extension kind" manifest property https://code.visualstudio.com/api/advanced-topics/remote-extensions#architecture-and-extension-kinds you will notice that Docker extension fits the description of "workspace" extension much more than "UI extension"

If you want to see Docker assets on the local machine, install the extension locally and open a VS Code instance that uses local machine context. If you want to see Docker assets on the remote machine, install it remotely and open a VS Code instance with a remote connection. It is quite predictable this way.

[leighmcculloch]

Thanks for explaining. For my use cases the example @bwateratmsft posted in #3051 (comment) using remote.extensionKind to override the setting is perfect. Thanks!