Create or provide choice for multiple R versions and x64 or i386 architectures for R terminal

[gwd666]

Is your feature request related to a problem? Please describe. No problem only a feature request ... When hitting CTRL+P the R: Create R terminal command opens up the VSC Terminal and starts a R session based on the Rpath (in my case WINdows) setting, but only allows for one distinct R architecture (either x64 or i386) and R version

Because of (mainly database client) driver architecture issues on Windows (ODBC etc) this means a lot of manual hassle with extension Settings in case one would like/need to switch to R i386 architecture (in my case b/c x64 is usually my default) or vice versa.

Describe the solution you'd like Choice between R: Create R-x64 terminal R: Create R-i386 terminal

Maybe even side by side?

Describe alternatives you've considered None so far - I am open for workarounds (eg keyboard shortcuts or similar).

Additional context NA

PS: this extension of yours ROCKS!

[renkun-ken]

Have you tried typing in the terminal to start R-x64 and R-i386 terminal and do both work?

[gwd666]

Hi Sorry I do not fully understand your proposal or hint. If I execute a fully qualified path to R_HOME\bin\i386\R.exe or ...x64\R.exe versions in the Terminal the respective R version will start up, yes. ALSO the "normal" R/Rterm that I defined in Settings works like a charm as well - no "bug"or so involved here in this "ticket"!

I was just hoping for a small enhancement to VSC R to be available when hitting the CTRL+P keyboard shortcut. One could probably also assume that the respective architectures will be available from R_HOME\bin\ in the i386 and ...x64 subfolders. Not so sure about how that would look like / work with radian (since I do not use that). But for defining Rterm path in the R extension Settings you would also have to decide the ARCH - a lot like in RStudio, where you always have to restart after changing the ARCH, but I thought maybe these Setting changes could be avoided for the R: Create R terminal command, if this was available via CTRL+P? No worries - it still is mainly just a "feature request" (imho) for UX and def not a bug! What is your opinion - you think that is useful? The use-case is that I have some packages that require 32-bit R (as mentioned above because of some 32 bit driver architecture for Windows mainly ODBC stuff) and I sometimes forget about having to change that default Rterm path Setting and after a couple of weird Errors and changing it for some development I also always need to remember to revert it back again, etc. Would be more convenient to have that around with CTRL+P, I was guessing.

[gwd666]

OTHERWISE ... I forgot to mention that for R DEV work I can or usually always do "tweak" the Workspace R extension Setting accordingly! It is mainly when I use VSC interactively ie when I use that package (with its 32 bit driver dependency) that I tend to forget or need to switch the R-ARCH in the "User" Settings.

[ManuelHentschel]

I can 100% understand where you're coming from, but I'm not quite sure what the best approach would be here. E.g. when a new R version is released which I want to try, but not switch to permanently (yet), I'm in a similar situation as you, but not between architectures but R versions.

Also, e.g. in https://github.com/REditorSupport/vscode-R/issues/597 we're looking to simplify the path settings, to make using the extension easier for new users, and adding support for different architectures/versions is somewhat contradictory to this.

The alternative that currently works best for me is to not use r.path.xxx and r.term.xxx at all, and simply have the version I'm currently using on the PATH. Or if the R path is project specific, using the settings.json, but you already mentioned that that wouldn't help with your current issue.

A solution that might work for you without making the configuration more complicated for new users might be the following:

• Have an extra (hidden?) setting, where you can specify additional R paths.
• The first time, an R path is required by vscode-R, the user is asked, which R path to use (similar to what the python extension does)

This would be opt-in without cluttering the regular path settings for most users and flexible enough to be used for different architectures/versions etc.. And un-setting this setting in a given workspace would avoid asking for the R path all the time.

[renkun-ken]

What if we accept multiple paths in r.term.xxx? User could specify a single path (currently supported) or multiple paths separated by ;. If multiple paths are specified, then "R: Create R terminal" will show a picker for you to decide which one to use?

@ManuelHentschel @gwd666 Does it sound okay?

[ManuelHentschel]

Sounds good!

Note that on windows ; can be part of a path, but e.g. requiring such paths to be quoted should work fine.

I'd also suggest implementing the same mechanism for r.path.xxx.

[gwd666]

I can 100% understand where you're coming from, but I'm not quite sure what the best approach would be here. E.g. when a new R version is released which I want to try, but not switch to permanently (yet), I'm in a similar situation as you, but not between architectures but R versions.

This [multiple R versions] is definitely also a very valid and common scenario. @renkun-ken @ManuelHentschel - I do like the multiple paths approach, especially since this would as a result fix one of the major inconveniences you usually have in RStudio in the VSC editor. Looking forward to your ideas and if this feature will make it into one of the future releases. Thanks ...

[renkun-ken]

I'd also suggest implementing the same mechanism for r.path.xxx.

If multiple paths are specified in r.path.xxx, then starting background processes (e.g. R help, language server) should prompt?

[ManuelHentschel]

If multiple paths are specified in r.path.xxx, then starting background processes (e.g. R help, language server) should prompt?

Yes, once per session. Normally, people will have only one path here, but if someone decides to put multiple paths in r.path.xxx, this is the behaviour I'd expect.

Edit: Also, should the r.term.xxx be decided for each terminal individually or once per session? For my personal usecase, once per session would be enough, but others might prefer to choose for each terminal.

[ElianHugh]

If its of any use, the python extension does a neat thing where you can set the interpreter

https://code.visualstudio.com/docs/languages/python

[renkun-ken]

I was thinking about exactly the same thing as @ElianHugh suggests.

[gwd666]

@renkun-ken and @ElianHugh - I also like the idea of not reinventing the wheel and presenting people with something "familiar" partly also b/c the intersection of Py and R users (bilingual ones using both extensions) is probably quite significant and that similarity could end up being a nice "muscle memory" feature then

[gwd999]

One could probably also assume that the respective architectures will be available from R_HOME\bin\ in the i386 and ...x64 subfolders. Not so sure about how that would look like / work with radian (since I do not use that). But for defining Rterm path in the R extension Settings you would also have to decide the ARCH - a lot like in RStudio, where you always have to restart after changing the ARCH, but I thought maybe these Setting changes could be avoided for the R: Create R terminal command, if this was available via CTRL+P?

you can also define the desired architecture as an argument when calling R_HOME/bin/R Taken from R Install Admin manual: Sub-architectures are also used on Windows, but by selecting executables within the appropriate bin directory, R_HOME/bin/i386 or R_HOME/bin/x64. For backwards compatibility there are executables R_HOME/bin/R.exe and R_HOME/bin/Rscript.exe: these will run an executable from one of the subdirectories, which one being taken first from the R_ARCH environment variable, then from the --arch command-line option with possible value: ‘i386’, ‘x64’, ‘32’ and ‘64’ so eg.: R_HOME\bin\R --arch i386

[hermidalc]

In https://github.com/REditorSupport/vscode-R/issues/1130 I'm pretty much asking for the same thing and what isn't mentioned here is many R users will not have a single R install and will use something like mamba/conda where, per project/github repo, one will have a conda environment with it's own R, radian, and libraries each with their own versions/builds required by that particular project.

The feature request for me would be to make vscode-R work exactly the same as vscode-python. I should be able to hit Ctrl + Shift + P -> R: Select Interpreter and an auto-populated drop-down list of all the R binaries avail on my computer will be shown and I should be able to select this binary (and by extension the conda env) per project folder (or workspace level).

Then in the lower right-hand status bar should show in place of the Python (Extension) status info it should have the R (Extension) status info with e.g. 4.1.3 ('myenv': conda)

Also this entire thing with R: (not attached) should be seamless and automatically attach the R/radian from above.

[ElianHugh]

I've done a bit of work on this recently. I've successfully retrieved a list of paths, versions, and architectures on Linux so hopefully implementation isn't too far off. Just looking at retrieval from renv (i.e. using r version specified in the lock file) and conda now

[hermidalc]

Thank you @ElianHugh

Hopefully it will work like I’ve described above like python extension does, then this would make a lot of sense to new users. This would be a very useful feature to the R extension

[gwd999]

Though 32-bit R is soon being deprecated choosing different versions is still a cool feature. Just curious if there is going to be a way for radian integration for that? Currently I am using —r-binary= … when having a radian path defined for R. Maybe some environment variable could be derived from that „new“ R version path and be used as a stand-in there? Not sure but I think radian and r.paths per project already could and imho should be handled in [Workspace] .vscode/settings,or? Would have to lookup if there isn‘t already the User vs Workspace functionality in the „extension settings“ available for that? Think last time I did not succeed in that, but maybe I missed some details. Really looking fwd to that feature.

[ElianHugh]

Thanks. Regarding radian, I've played around with setting the R_BINARY environment value, which appears to work + is relatively unobtrusive. This would be accessed via the provided R terminal profile.

Edit:

With regard to per workspace settings, I think the way to go is with memento API provided through the extension context object -- I believe this is how it's handled in python

[hermidalc]

I also cannot seem to even get vscode-R linting to work. Coming from Atom where things just worked it's kind of frustrating. All the vscode python stuff everything works beautifully. It's sort of feels like R support is kind of an afterthought in VSCode (I try to mean this in a constructive way! I want it to work and I'm not a novice user)

For R I've installed everything in a single conda environment and then I launch code from the terminal with that environment activated. I also specified the full path to that conda environment R binary in the r.term settings. This should be equivalent to someone installing everything in their system path. But nothing works for me I open an R code file and it doesn't lint, it says Loading... on hover over, attaching doesn't work, basically nothing useful works. Kind of frustrating for a new user and trust me I know my way around I've been using Atom for like 5 years.

[ElianHugh]

I can sympathise with the frustration. The issue by-in-large is likely with regard to the use of conda environments, which have historically had issues with this extension. Hopefully this will be resolved when this feature gets PR worthy

[hermidalc]

The thing is though I'm not getting that explanation, why does the vscode-R extension not look at what binaries are available in the user's $PATH? If I've launched code from a terminal with the conda environment that has the all the binaries needed activated? This is how Atom would work. In Linux that's completely equivalent to installing binaries system-wide via apt/dnf packages, which if I'm understanding correctly you are saying it would work if I did it this way. Sorry just my new user frustration.

Hopefully like you said your PR will work exactly like vscode-python is designed, which is really great and much better than Atom. You don't need to install anything system-wide or launch code from a terminal, it can simply be launched from your GNOME desktop and just works.

[ElianHugh]

Still WIP but getting there:

[hermidalc]

@ElianHugh and that executable setting can be set for each project folder in a workspace and it remembers it? And how does it work the R: (not attached)? I could also not get that to work, it would just .vsc.attach() do nothing in the terminal.

[ElianHugh]

Yep, the R version is set on a workspace basis, so each time you open it up it will use the version that you set. If there isn't one set it'll default to the rpath in settings, otherwise will prompt user to choose.

I'm still thinking about what to do re: the terminal. The whole not-attached thing probably also needs some special treatment for conda environments (e.g. need to auto-activate for users). Also, it'll now follow the R version specified but it looks a little redundant having two R buttons there. Any thoughts on the issue @renkun-ken ?

[hermidalc]

Hey @ElianHugh it should be on a project folder basis not workspace basis, just like vscode-python has these settings on a project folder level. It makes dev sense too because each project folder is a github repo, which usually has it's own (conda) dependency environment (i.e. it's own conda env yaml file)

[ElianHugh]

When you say project folder basis, what kind of setup do you mean? Something like:

• workspace
  • ProjectA
  • ProjectB
  • ProjectC

[hermidalc]

Yes that's a project folder in a workspace and each one is it's one github repo usually. It's just like vscode-python designed it I can set my conda environment and executable at the ProjectA ProjectB and ProjectC folders separately. It's exactly the way you want it as a developer.

The workspace is just a collection of related github repos (projects). A dev could have things the same between projects and just set it at workspace level, but that's not often the case.

[ElianHugh]

Alright, I getcha. I'll have to look at how python handles the languageserver sessions

[hermidalc]

Here's my current VSCode screen. My workspace right now is my collection of sklearn/sksurv based framework and extension projects (each its own github repo). For example, sklearn-bio-workflows has a different conda environment and deps than sksurv-bio-workflows. In this case same python but in other examples the project folders have different pythons and related deps.

When I have my cursor active in a code window from sklearn-bio-worflows you see in the bottom right-hand corner is automatically switches to its conda environment:

When I have my cursor active in a code window from sksurv-bio-workflows you see it automatically switches to its conda environment:

[hermidalc]

And sorry forgot to mention a super important other reason. Since the projects have different environments and dependencies, the auto switching of environments between code windows from separate projects enables the syntax checking, autocomplete, and signature help of deps to work seamlessly.

For one project I might have lifelines as a dep in the environment and the use of lifelines in a code file will work and do the right things. vscode-python does all this.