I am currently trying to set up a new development environment, using VSCode, WSL, and the WSL Remote Extension. The environment will also utilize Git, and will sign commits via a YubiKey.
I initially tested this out the setup on a Windows 10 machine, using wsl2-ssh-pageant, and that worked flawlessly. I could sign commits straight from my WSL environment, and everything was awesome. Then I tried implementing this on my work machine, which is running Windows 11... Nothing is awesome.
Apparently there are a whole bunch of issues getting something like this to work on Windows 11, and the author of that library has abandoned the project. I have tried finding an alternative, testing things like npiperelay, wsl-ssh-agent, and a ton of others (too many to list), but the issue always comes back to Windows 11 (and downgrading is not an option).
Therefore, I decided to try a different approach. I can sign commits from Windows 11, using the Yubikey, without issue. So I wanted to get VSCode to use my local Windows 11 Git installation, rather than the WSL one. However, even when configuring git path in the settings, to use the Windows 11 Git, it seems to be using it inside a WSL container, meaning the Yubikey is unreachable; so all signing fails.
I should probably mention that both WSL and Windows 11 has access to the folder.
My current workaround is to do my development in VSCode, and then do all Git commands in a Windows 11 Terminal, which allows me to do signing, but it skips all the VSCode GUI and fancy tools, so I would like to keep everything in a single place.
So my question is: Is there a way to develop in WSL via VSCode, using the remote extension, while making VSCode do all Git operations on the host system (completely ignoring WSL)?
Related
I've liked using VS Code's integrated terminal in my VS Code windows. I usually have several different windows open, each in a different project, and use the terminal to interact with the git repository for the project and the compiler. However, currently (I think this changed in the June 2022 update?) it seems the integrated terminal has started sharing the working dir across VS Code windows, so that if I cd to a particular project/repository in one window, the terminal tab in other windows also change directory.
Assuming this is intentional, is there a way to use the integrated terminal in a way that keeps terminals in separate windows completely independent?
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!
I've used Git Bash for most bash-required tasks before, but since I've found WSL to be much more feature-rich as it's basically an entirely new subsystem. However, when I used to use VSCode along with Git Bash, it would simply cd into the working directory of the project for ease of use. However, it doesn't do that here. The only solutions I've found online are to create an entirely new Remote WSL VSCode window, but this is way too high maintenance for what I'm trying to do as I'm literally just trying to get VSCode to automatically cd into the correct directory. Thanks in advance.
I recently stumbled on AWS Cloud9 and Spacemacs and genuinely impressed with both of them.
The problem is I cannot make Spacemacs to work properly on remote environment development just like Cloud9, all this time I was using VSCode with Dropbox and sync with local folder.
I tried with ftp, X window, dired remote mode (and similar Remote VSCode in the VSCode extension), none is satisfactory. I need it for all the full-blown features, remote code listing, debugging, versioning (I use mercurial).
Spacemacs is more than ok in the local development and I think VSCode just need to take a liitle more steps to rule them all.
After trying numerous solution, Samba, NFS,etc, the closest thing to Cloud9 is OSXFuse, so you can use both Spacemacs or VSCode and get local development feels. But I haven't found solution for Windows, perhaps will be less complicated.
Is there a better way to setup Eclipse CDT for local editing and remote building?
I am working on a C++ project that uses GNU make in Linux. The code is under CVS on a Linux server.
When I'm in the lab, I use Eclipse CDT on a Linux-x64 PC. The project is built on a Linux-x86 PC. All the computers in the lab (including the CVS server) have NFS mounts.
When I'm at home, I use Eclipse CDT on a Windows 7 PC. The Windows PC connects to the Linux CVS server via SSH tunnel. To edit source, I rsync the C++ project under the Linux Eclipse workspace back to my Windows Eclipse workspace. (I can also do a remote CVS checkout on the Windows PC.) To build from home, I use a custom build command that
SSH's to the Linux-x86 PC,
rsync's the C++ project from my Windows Eclipse workspace to my Linux Eclipse workspace,
and then runs make on the Liunx-x86 PC, specifying the correct path for the Makefile.
In order to go back and forth between lab and home without committing my changes to CVS every time, I use rsync. When I transition from lab to home, I rsync sources to my Windows Eclipse workspace. When I build from home, the sources get rsync'd back to the Linux Eclipse workspace.
Is there a better, less wonky way to do this?
(I'm NOT interested in remote debugging.)
Netbeans has good support for this. I've tried to get it working in Eclipse, but Netbeans was much easier with built in support.
One solution is to use Eclipse RSE (Remote System Explorer). It allows to "mount" a remote subfolder directly into the workspace (via FTP or SSH). CDT has some issues with the virtual file system used by RSE, but it ... well, more or less works.
There's some discussion on that on my question:
Work on a remote project with Eclipse via SSH
I need to do similar things, and I took a look at Synchronized Projects:
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.ptp.doc.user%2Fhtml%2FlocalVsRemote.html
Synchronized projects support multiple build configurations, so the build can happen either locally or on one or more remote systems. The user can select which system will be used to build the project. A launch configuration can then be created to to run the application on the target machine.
To build on remote machine, follow Working with a Synchronized Project: http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.ptp.doc.user%2Fhtml%2Fsync.html
How about using vnc and remotely logging in, using eclipse ON your unix box in the lab?
The only thing to go across the link is your editing, and vnc is pretty efficient about that.
This post seems quite old. But in case this might help somebody, I'd like to post a solution that works both on Linux and windows machines, which is really easy.
Now there is an Eclipse parallel version and you can just install that and change few lines in your remote machine's bash_profile to load few git functions. I'm even connecting from behind a gateway which is a little tricky. It is easier without. See this link:
http://umayanganie.blogspot.com/2017/05/build-debug-cc-projects-via-remote.html