I want to install VS Code + some extensions (Java to be exact) on the PCs (CentOS) in our university lab. I installed the editor itself according to the official documentation, but I'm running into problems when I want to install extensions. I'm logging into the systems as root via ssh.
Running sudo code --install-extension vscjava.vscode-java-pack --user-data-dir /some/dir (source) runs successfully, and the extensions are available when VS Code runs as root. The problem is: When I start VS Code as another user, the extensions are not installed.
My questions are:
What is stored in the user-data-dir? Does it contain the location of the extensions-dir? If yes, is it wise to share it across all users of the system?
What is the recommended way to install extensions system wide for different users?
Thanks!
I also need to be able to install extensions systemwide, but there doesn't seem to be a way to do this. The best solution I've found is to write a batch file that installs the extensions and then starts VS Code. I have users run that scr
Related
I'm using wsl and it runs codes in vscode pretty fine and I have different libraries which I installed through pip and conda in wsl but when I run that code using vscode itself it doesn't recognize the libraries or even pip itself.
I don't have any other environment.
I should add that I installed the packages globally using conda install ... or pip install ... in base environment and I only have base environment and I run my code through code . and I also have python and remote wsl extensions installed in my vscode.
what can be the problem?
I don't have much personal experience with this, but I found some useful information in this Stack Overflow question (even though it doesn't utilize conda), along with https://code.visualstudio.com/docs/remote/wsl-tutorial#_python-development.
I also found this blog post useful, even if it doesn't cover WSL.
In short, make sure you:
Have installed the Python extension (by Microsoft) in VSCode. This is critical for being able to detect and select the Python interpreter. You don't mention having this in place, so I believe this is your likely problem.
You have done this already, but including it for others who might read this later -- Install the Remote - WSL extension (or the Remote Development extension pack) in VSCode.
You are also doing this already -- Start VSCode from inside your WSL distribution. Alternatively, you can start VSCode from Windows and then select the Remote WSL - Reopen Folder in WSL from the Command Palette (also accessible from the "Remote" Status Bar).
In VSCode, open the Command Palette with Shift+Ctrl+P, search for the Python: Select Interpreter command, and you should find your Conda environment in the list.
After selecting this, you should find that your project is using the interpreter and modules that you have installed via conda.
One thing I did to overcome this issue is go to Extensions -> Local (You should have two tabs there, Local and WSL:DISTRO) DISTRO refers to whatever DISTRO you're using, you will see that some of the local extensions are disabled in the current workspace (WSL) and there is a little cloud icon in the WSL:DISTRO tab that says install Local Extensions in WSL:DISTRO once you click that it will let you choose which extensions to install and you should be good to go!
If you have multiple developers w/ multiple developer workstations and they each have VS Code, how can I track what extensions that have from a central location? I don't want to have to sign on to each workstation one at a time and pull up VS Code for a list of installed extensions and versions. FOr example, there is a vulnerability in VS Code's TS-Lint extension. How can I tell what computers in my group have that installed?
Method 1: Query the File System
The Common Questions section of the page Managing Extensions in Visual Studio Code shows where extensions are installed:
Where are extensions installed?
Extensions are installed in a per user extensions folder. Depending on your platform, the location is in the following folder:
Windows: %USERPROFILE%\.vscode\extensions
macOS: ~/.vscode/extensions
Linux: ~/.vscode/extensions
The extensions directory contains one subdirectory for each installed extension, named like (extension)-(version). Listing its contents for each user and machine should provide a comprehensive list of installed extensions.
Method 2: Query VSCode Itself
Another approach is to use the VSCode command line as explained in the Command Line Extension Management of that same page. In particular, you can run:
$ ./bin/code --list-extensions --show-versions
from the VSCode install directory when logged in as a particular user to get a list of (extension)#(version) strings.
But note: you have to use the code program in the bin subdirectory of VSCode, which is a shell script (requiring Cygwin on Windows). On Windows at least, there is also Code.exe in the top-level VSCode directory, but that one does not respect those command line flags.
I use VS Code as my main code editor for my C++ development. I am using the remote SSH extension by Microsoft to access my office workstation from home. For the C++ autocompletion and linting I use the clangd extension by LLVM. Company policy prevents users from having sudo access to workstations and libraries are often not at the latest version.
When I try to launch clangd I get the following error message:
/lib64/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by /my/path/to/clangd)
Which obviously means that the version of libstdc++ is too old for the version of clangd that I am using. This is easily fixable by adding to LD_LIBRARY_PATH the location of most recent gcc libraries (part of our compiler toolchain) and then launching VS Code.
However, now that I am working remotely I cannot do that because VS Code is installed onto my laptop and I am using the SSH extension to access the code on my office workstation. Looking on the man page for clangd I cannot see a way to specify the path to the libstdc++ that I want to use. Is there a way, other than adding the libraries to the LD_LIBRARY_PATH upon startup/login, to bypass this issue?
I found a way, albeit a little bit hacky.
Export the new LD_LIBRARY_PATH on .zprofile (or equivalent for your shell. I am using zsh). Make sure that there are no VSCode servers running in the host. If there are, make sure to remove them.
In the settings.json file add the following line, to tell VSCode that you want the shell to be a login, interactive shell:
"terminal.integrated.shellArgs.linux": ["-l", "-i"]
Job done. Clangd now finds the correct libraries.
Another way to do this is to use env in your settings.json as follows:
"clangd.path": "env",
"clangd.arguments": [
"LD_LIBRARY_PATH=<your_custom_path>",
"/path/to/my/clangd"
],
Recently I updated my Windows 10 Pro with May Update (version 1903, build 18362.116). Then for my existing distros: OpenSuse Leap 15 and Ubuntu (installed from MS Store), I wanted to open a linux directory by using Explorer and I'm getting this message:
[susedis#mypc ~]$ explorer.exe .
If 'explorer.exe' is not a typo you can use command-not-found to lookup the package that contains it, like this:
cnf explorer.exe
This problem happens also with VSC (code) and VSC-Insiders (code-insiders).
I've read this article and ...
OPTION 1: my current problem
OPTION 2: icon LINUX does not exist in tree view
OPTION 3: it works
Supposedly options 1 and 2 should exist and work, even more with the latest update. What's wrong? Thanks in advance.
PS1: I've found these articles Run Visual Studio Code for Linux from WSL and Using Visual Studio Code with Windows Subsystem for Linux, they talk about installing xserver and more stuff on side linux. But many other articles and videos don't talk about it, it's like it was a built-in feature of Windows. This is so dark.
I just found what is the root of my problem: the distro.
explorer, code, code-insiders commands ONLY work through UBUNTU and I was using OpenSuse.
This warning is lacking in every article on Web I read, including on VSC site (example: Developing in WSL). This is a disadvantage for other distros. Very bad.
PS1: The solution can be found here.
I just started with VS Code today as I have to prepare to port some of my code to Linux and I noticed that in the Terminal section there is the option of having a WSL bash, so I thought I could use this to compile my projects with gcc right there. I already installed Ubuntu for Windows 10 from the MSFT Store some time ago an installed several packages there. The thing is that the Ubuntu bash doesn't seem to share to the Linux workspace with the bash I see in VS Code, since in the latter I am lacking all those packages I already installed; it seems to be a completely different installation. Also, I noticed that the bash in the VS Code terminal uses German language while the Ubuntu App's bash is in English. (I have no idea why this is since Windows as well as VS Code is English.)
I'm quite confused about these differences, how do ubuntu.exe and bash.exe relate to each other? Can anybody shed some light on this? Obviously, it would be preferrable to to have only ONE Linux workspace in WSL so I don't have to have duplicates (of my data and also the installed packages) at different places.
To use WSL bash in VS Code integrated terminal, you need to add/change setting:
"terminal.integrated.shell.windows": "C:\\Windows\\System32\\bash.exe",
Restart VS Code or integrated terminal.
If two or more WSL distro are installed, then you need to specify the path to the desired distro.
For example you can find it by running: where ubuntu, where ubuntu1604 or where ubuntu1804. And change the settings to the desired ones. For example:
"terminal.integrated.shell.windows": "C:\\Users\\USERNAME\\AppData\\Local\\Microsoft\\WindowsApps\\ubuntu1604.exe",