vscode: Ordering of installation of vscode:extensions matters and leads to errors on loading
Behaviour:
-
Upon opening a GitHub code space with the following configuration of extensions, I get an error saying that one of the extensions are not installed (but it should be installed since it is in the list).
-
VS Code Version: Version: 1.83.1 (Universal) / Commit: f1b07bd25dfad64b0167beb15359ae573aecd2cc
-
OS Version: macOS 13.6 (22G120)
Steps to Reproduce:
- Use GitHub code spaces with the following .devcontainer (see below)
- Open the GitHub code space
- When loaded you get the error: “Cannot activate the ‘autopep8’ extension because it depends on the ‘Python’ extension, which is not loaded. Would you like to reload the window to load the extension?”
Diagnosis:
In speaking with the GitHub code spaces team, I learned that:
- “It looks like all of the extensions are being passed into the VS Code server at the same time, so it would require upstream changes in VS Code to handle the installation order in a better way.”
and
- “My guess is that the extensions are installed in parallel and the python one just takes longer to install/activate and the pep8 one is trying to activate too early before the python finishes installing”
devcontainer.json includes
{
"name": "Python 3",
"image": "mcr.microsoft.com/devcontainers/python:0-3.11",
"features": {
"ghcr.io/devcontainers-contrib/features/poetry:2": {},
"ghcr.io/devcontainers/features/github-cli:1": {}
},
"customizations": {
"vscode": {
"extensions": [
"ms-python.python",
"ms-toolsai.jupyter",
"eamodio.gitlens",
"redhat.vscode-yaml",
"GitHub.copilot",
"ms-python.vscode-pylance",
"ms-python.autopep8"
],
"settings": {
"python.testing.pytestArgs": [
"data"
],
"python.testing.unittestEnabled": true,
"python.testing.pytestEnabled": true,
"[python]": {
"editor.defaultFormatter": "ms-python.autopep8",
"editor.formatOnSave": true
}
}
}
}
}
About this issue
- Original URL
- State: closed
- Created 8 months ago
- Reactions: 4
- Comments: 26 (11 by maintainers)
PR to fix: https://github.com/microsoft/vscode/pull/203972
I have been running into this same situation, except inside a devcontainer. The Black Formatter extension and the Flake8 extension fail 100% of the time and VSCode suggests reloading. Reloading always works.
Is anyone aware of a workaround in the meantime to enforce an ordering?
I’ve also been seeing such issues for months, particularly for extensions that depend on
ms-python.python.As someone maintaining the development setup environment for a team, it would be really helpful to have any solution that works without a manual reload or custom configuration for each user.
thanks @sandy081 🎉
I stumbled upon a workaround with a long-running
updateContentCommandin .devcontainer.json, so I suspect for anyone having this issue you could potentially do something like:Not pretty, but neither is the “always click the reload button” option.
Thanks for feedback. I closed this because I do not see us investing resources in fixing issues like this in the next 6 months. Not saying it is invalid. We might still reopen it after I discuss with @sandy081
As for GitHub - I suggest to reach out to the Codespaces team and if they have capacity they can invest in making a PR.
Or at least loading extensions in the order as given in the
extensionslist, then users could at least easily hand-sort to avoid these annoying dependency problems until a “real” fix comes along. Presumably/hopefully this could be a quick fix as it’s a small change?this issue shows another simple repro example, they even provided a repo that reproduces this issue every time and it only has two extensions listed in devcontainer.json: https://github.com/PelicanQ/devcontainer-issue.git
I’m seeing the same behavior as @mjpizz with a slight clarification:
I have the following in my .devcontainer.json:
Order (moving python above black-formatter, flake8, and isort) doesn’t seem to matter.
Visual Studio Code Version: 1.84.2 (user setup) Commit: 1a5daa3a0231a0fbba4f14db7ec463cf99d7768e Date: 2023-11-09T10:51:52.184Z Electron: 25.9.2 ElectronBuildId: 24603566 Chromium: 114.0.5735.289 Node.js: 18.15.0 V8: 11.4.183.29-electron.0 OS: Windows_NT x64 10.0.19045
Will investigate and see if I can repro
I have to admit that I’m confused. The linked page talks about closing out-of-scope feature requests. I don’t see how this can be relevant here, as this report is of extension loading being broken/erroring. In fact, I’m confused why the
buglabel was removed by @sandy081. Furthermore, users have supplied logs as requested, and even repos for reproduction, yet theinfo-neededlabel was not removed, and now failing extension loading is closed asout-of-scope?@isidorn I’d be curious about the decision process here, to be honest. 😞 ☮️
@sandy081
Repro steps
I use this link to open the
seesharprun/codespace-testrepository as a codespace:https://codespaces.new/seesharprun/codespace-test?quickstart=1&devcontainer_path=.devcontainer%2Fdevcontainer.json
Relevant devcontainer configuration:
I waited for the C# extensions to install and to observe the “Cannot activate the ‘C#’ extension because it depends on the ‘.NET Install Tool’ extension, which is not loaded. Would you like to reload the window to load the extension?” popup.
F1 > Open View > Server
Here’s the logs:
We have a similar issue with C#. If you install the C# extension or the C# DevKit extension, it will install quicker than it’s dependent “.NET Install Tool” extension.
This race condition leads to a prompt that shows up the majority of the time to reload the editor to install the dependent extension.