Blocking prompts

[tschaub]

When opening a workspace with a .devcontainer/devcontainer.json file, I get prompted with four separate but related dialogs. See the movie below for an example.

In the movie above, I get four dialogs: 1) folder contains a Dev Container configuration, 2) use Pylance, 3) install flake8, 4) install pytest. Dialogs 2, 3, and 4 hide dialog 1. However, dialogs 2, 3, and 4 "depend" on dialog 1 – the reason I'm prompted about these things is because the project is meant to be opened in a container (where flake8, pytest, and Pylance are available). It is awkward to have to dismiss one of the related dialogs (2, 3, or 4) to make a decision about the primary issue (dialog 1).

I'm not sure whether this feature exists in VSCode, but it would be nice if these dialogs or prompts could depend on one another. I shouldn't have to make a decision about installing flake8 etc until after I have decided whether or not to open the project in a container.

So this may be a general VSCode feature request instead of one specific to the vscode-remote-release project, but it has a high impact on the usability of this project (see also #2133).

[chrmarti]

/causedByExtension

It looks like you have installed the Python extension locally and that asks you to install Python tools you don't have. Try uninstalling the Python extension locally, you probably only need it in the container (where it will still be installed if you list it in the devcontainer.json).

And/or: file a new issue for the Python extension: https://github.com/microsoft/vscode-python/issues/new/choose

[tschaub]

I use the Python extension for other non-containerized projects (and those projects have dependencies installed in their own environment). So the only place where things aren't working is with projects that use the Remote-Containers extension.

[chrmarti]

Maybe you have paths in the project's .vscode/settings.json that are only valid inside the container?

[tschaub]

Yes, the path to the interpreter is different in the container and on my system (I assume this is frequently the case):

{
  "python.pythonPath": "/usr/bin/python",
  "python.testing.pytestArgs": [],
  "python.testing.unittestEnabled": false,
  "python.testing.nosetestsEnabled": false,
  "python.testing.pytestEnabled": true,
  "python.linting.flake8Enabled": true,
  "python.linting.pylintEnabled": false,
  "python.formatting.provider": "autopep8",
  "files.autoSave": "afterDelay"
}

Maybe swerving off topic, but when using the Remote – SSH extension, I can place settings (like python.pythonPath) in a *.code-workspace file. Then I can code my.code-workspace to launch VSCode using the remoteAuthority and the settings that are relevant for the remote. I assume that if it were possible to use the Remote – Containers extension in a similar way - launching VSCode with a configuration specific to the container - I wouldn't be running into this issue where the editor is finding problems with my host environment before I can tell it that what I want is to connect to the remote.

[chrmarti]

You can place settings specific to the container in the "settings" property in the devcontainer.json file. Or you can use workspace file (with the limitation that the workspace file's folder must contain all workspace folders - as direct or indirect subfolders).

[tschaub]

Thanks, @chrmarti. That helped. When I move the python.pythonPath setting from .vscode/settings.json to .devcontainer/devcontainer.json, the experience is nicer (I only see the one "reopen in container" prompt).

I'm wondering if there is something that could be changed in this extension to improve the experience. When I run the "Python: Select Interpreter" command, whose responsibility is it to determine where the selected path gets written? I think I first ran that command after I had chosen to "reopen in container" - and (wrongly) assumed that the setting would be container-specific.

[chrmarti]

This is the Python extension writing the setting. They could write the setting to the machine settings and the devcontainer.json when connected to a container.

Closing thanks.