Open Wittano opened 2 years ago
Thank you for taking time to report this, I thought I had been going crazy.
I also encountered the same problem.
I read the source code of this extension. I think this is an underlying flaw of this extension, related to the VSCode extension activation order.
In order to start fast enough, VSCode does not provide an API to define the order of extension activation.
Therefore, in some cases, other extensions will start before this extension completes env/set-current-env
.
Taking the Go extension as an example, if I don't open the go source file, it will work fine, the extension host output is:
2023-03-04 17:50:41.355 [info] ExtensionService#_doActivateExtension arrterian.nix-env-selector, startup: false, activationEvent: '*'
2023-03-04 17:50:41.355 [info] ExtensionService#_doActivateExtension mutantdino.resourcemonitor, startup: false, activationEvent: '*'
2023-03-04 17:50:41.356 [info] ExtensionService#_doActivateExtension vscode.extension-editing, startup: false, activationEvent: 'onLanguage:markdown'
2023-03-04 17:50:41.356 [info] ExtensionService#_doActivateExtension vscode.markdown-language-features, startup: false, activationEvent: 'onLanguage:markdown'
2023-03-04 17:50:41.356 [info] ExtensionService#_doActivateExtension DavidAnson.vscode-markdownlint, startup: false, activationEvent: 'onLanguage:markdown'
2023-03-04 17:50:42.638 [info] ExtensionService#_doActivateExtension vscode.git, startup: false, activationEvent: '*'
2023-03-04 17:50:42.638 [info] ExtensionService#_doActivateExtension vscode.github, startup: false, activationEvent: '*'
2023-03-04 17:50:42.816 [info] ExtensionService#_doActivateExtension vscode.markdown-math, startup: false, activationEvent: 'api', root cause: vscode.markdown-language-features
2023-03-04 17:50:42.972 [info] ExtensionService#_doActivateExtension golang.go, startup: true, activationEvent: 'workspaceContains:*.go,*/*.go,*/*/*.go'
If I open the Go source file, the Go extension will report an error, and the extension host output is:
2023-03-04 17:49:58.989 [info] ExtensionService#_doActivateExtension arrterian.nix-env-selector, startup: false, activationEvent: '*'
2023-03-04 17:49:58.989 [info] ExtensionService#_doActivateExtension mutantdino.resourcemonitor, startup: false, activationEvent: '*'
2023-03-04 17:49:58.989 [info] ExtensionService#_doActivateExtension golang.go, startup: false, activationEvent: 'onLanguage:go'
Therefore, I think the implementation of this extension can only completely solve this problem by modifying the user's shell profile to inject environment variables such as PATH. For example ~/.bashrc
if [ $VSCODE_RESOLVING_ENVIRONMENT ]; then
# source ....
fi
If it is the first configuration, you need to completely restart VSCode to take effect. In the Remote SSH scenario, you need to kill (https://code.visualstudio.com/docs/remote/troubleshooting#_cleaning-up-the-vs-code-server-on-the-remote).
kill -9 `ps aux | grep vscode-server | grep $USER | grep -v grep | awk '{print $2}'`
I don't think anything can be done without modifying VSCode. Trying to fix it on the extension side ends up being hacky and buggy.
Weird situation. First time run extension, I selected my configured
shell.nix
file, extension loaded packages, everything works. Second time, extension didn't load my packages and LSP throws exception, because package didn't add to PATH. But when I close every tabs, that use any package from shell.nix, extension will load packages, add to PATH and everything back to normal.I found this bug for GoLang project. You can generate simple golang project and add to your shell.nix LSP for golang.