Vscode-r: Support for Windows Subsystem for Linux

[jacob-long]

I think you may be a Mac user, so I'll offer a little background information. New versions of Windows offer the ability to run a full version of Linux from the command line (not as a virtual machine, but as a real part of Windows). VS Code allows users to make Windows Subsystem for Linux (WSL) the default integrated terminal. It runs bash and will act exactly like Linux in terms of paths and things like that.

When I set "r.rterm.windows" to the WSL path of R ("/usr/bin/R"), the R terminal fails to open. I'm not fluent in TypeScript, so I can't be sure of the cause of the error, but I think the extension is checking whether the path exists before trying to open R. Since "/usr/bin/r" only exists in the Linux subsystem, it will fail that check if you're looking in the Windows file system. I'm not sure of the best strategy to address this, though it may be possible to check the Linux subsystem if the user has set WSL as their default integrated terminal.

[Ikuyadeu]

@jacob-long Thank you for your information!
Yes, I am Mac user, this problem is difficult for me. Sorry, I added help wanted label.
However, if you have some strategy, please tell me.

[hongooi73]

To run WSL binaries from the Windows command prompt, use wsl <command>. So to run /usr/bin/R, use wsl /usr/bin/R.

I haven't got R installed under WSL, but perhaps this would work:

{
    "r.rterm.windows": "c:/windows/system32/wsl.exe",
    "r.rterm.options": "/usr/bin/R"
}

[luciorq]

Can someone test if it works?

[codetrainee]

vscode team has released a new extension for wsl. https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-wsl

The Remote - WSL extension extension lets you use the Windows Subsystem for Linux (WSL) as your full-time development environment right from VS Code. This new, optimized support lets you:

Use Windows to develop in a Linux based environment, using Linux specific toolchains and utilities.
Edit files located in WSL or the mounted Windows filesystem (e.g. /mnt/c).
Run and debug your Linux based applications on Windows, in VS Code.
Remote - WSL runs commands and extensions directly in WSL so you don't have to worry about pathing issues, binary compatibility, or other cross-OS challenges. You're able to use VS Code in WSL just as you would from Windows.

[hongooi73]

Just a note: while I haven't tried it with WSL, the new remoting system works great with R running in a Linux VM.

EDIT: one wart I've found, plotting doesn't work. But everything else seems to be fine which is a pretty amazing achievement.

[ipstone]

I have a slightly different user scenario - while using mac vscode, I use the remote extension to work directly on a linux cluster.

Currently, I can send the R codes to the R terminal on the remote head node of the cluster; but I would love to know how vscode-R can send the codes to the interactive computation node (interactive bsub terminal ) on the cluster? Is there a setting in vscode-R can be changed to allow terminals with title 'nios' as the target terminal?

Update: just found my soluton: change the setting R - always use active terminal:
This solves my issue in using the interactive computation node on a cluster!

Thanks!

[hongooi73]

EDIT: one wart I've found, plotting doesn't work. But everything else seems to be fine which is a pretty amazing achievement.

And in fact, even this works now, albeit with some differences in behaviour. Creating a plot will redirect to the pdf graphics device, which by default creates a file Rplots.pdf in the project directory. Running dev.off() will write the plot to the file. To view the plot in VSCode, I found that this extension works quite well.

[renkun-ken]

@Hong-Revo Did you try session watcher with Remote - WSL? The plot should work out of the box I think.

[hongooi73]

@renkun-ken Just to clarify, I'm using Remoting with a VM in Azure, not WSL. Does session watcher still work in this scenario?

[renkun-ken]

@Hong-Revo If you are using Remote Development via SSH to a linux server in Azure, session watcher should just work out of the box. I'm working in this scenario on a daily basis and my very motivation to create the session watcher is in fact to make it work for this scenario.

[hongooi73]

Oh wow, that's awesome! I just tried it out. I do have one suggestion though; I'll make a new issue.

[renkun-ken]

Closing as no longer an issue with Remote Development via WSL.