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/or 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 and/or select R executable R: Create R-i386 terminal and/or select R executable

Maybe even side by side - or dropdown?

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.

[ElianHugh]

Hi @renkun-ken , this implementation would likely require the modification of the language service. Specifically, modifying the root folder away from workspace folder to some sort of project folder, so that we can distinguish between projects + have multiple servers running per project. This would also mean that we'd need a way of distinguishing projects (e.g., rproj file, description file, etc). Curious to hear your thoughts!

[hermidalc]

Here's so more fire in your belly for both @renkun-ken and @ElianHugh...

Do you want VSCode and vscode-R to steal people away from RStudio? RStudio isn't supported to run or even work with conda environments (https://community.rstudio.com/t/using-rstudio-within-a-conda-environment/128780 - from just a few months ago)

If you could make vscode-R work exactly like vscode-python, where the top folder level (each folder a Github repo) within a workspace it has its own distinct attached conda environment, associated R interpreter, libraries, and language server (all of which is what vscode-python provides), then this would be a killer feature over RStudio.

This is how those of us who write software in R that's meant to be distributed (not just do command-based data analysis) have our development environments set up. Because different Github repos will and software dependencies will need different versions and builds of R or dependencies will, and I have a different conda env yaml for each Github repo (VSCode top-level folder inside a workspace)

[hermidalc]

And please let me beta test this, as a new VSCode user coming from Atom, I know exactly how I would want vscode-R to work. Plus not to mention this will be a killer feature over Atom, Atom doesn't support this neither for python or R.

[hermidalc]

And to highlight more, this is what I mean by project folder (Github repo) level. When you open the VSCode Settings, you will see at the top User > Workspace > Folder. When dealing with vscode-python and Python extension settings, you see when selecting a project folder the extension settings are still there and things can be set at this level. But you see the vscode-R extension settings disappear at the folder level:

You can only see or change some of vscode-R settings at the workspace level. And the R interpreter path can only be done at the User level, which isn't usable for many of us I need a different R and dependencies for each Github repo. Some projects I have only can use R 3.6 because of various dependency needs, while others use R 4.1. Some project can use the same R version, but have different dependency version needs.

[gwd666]

@hermidalc just for my understanding but aren't some of the points above things that can (already) be handled via the renv package? or what would speak against using renv in those cases? excuse if I am missing something obvious that speaks against that package; and I am already using .workspace files most of the time to manage "r-binary" paths for my projects and a local .Renviron also can do a lot of good things in those scenarios, but I would of course also prefer a more "natural" R VSCode extension method to be available as mentioned before ideally resembling some of the Python extensions workflow (sort of "muscle memory" in that context)

[hermidalc]

@hermidalc just for my understanding but aren't some of the points above things that can (already) be handled via the renv package? or what would speak against using renv in those cases? excuse if I am missing something obvious that speaks against that package; and I am already using .workspace files most of the time to manage "r-binary" paths for my projects and a local .Renviron also can do a lot of good things in those scenarios, but I would of course also prefer a more "natural" R VSCode extension method to be available as mentioned before ideally resembling some of the Python extensions workflow (sort of "muscle memory" in that context)

Because renv is an R ecosystem only dependency manager. mamba/conda and conda-forge are a dependency manager that has python, R, perl, java, rust, etc dependency management. Most of the projects I work on use both python and R code in the same Github repo, and I'm sure for many others they do the same too. Good examples are using snakemake and rpy2 in your projects, which are great libraries and involve using python and R. Many people aren't bound or stick with a single language and ecosystem.

Using multiple languages seamlessly in the same project is what originally gravitated me towards Atom back when I started using it in 2017. Now that Atom's future is uncertain I'm trying to use VSCode but the R side is currently lacking.

[hermidalc]

Sorry to add something, VSCode already has full support for conda for Python, and at the project folder level which is what developers need, so all that infrastructure is there in VSCode for R to do the same thing. Why spend effort to support another dependency manager that is limited to only R when conda has full R dependency management plus for other languages.

[eitsupi]

Why spend effort to support another dependency manager that is limited to only R when conda has full R dependency management plus for other languages.

I believe many R users do not use conda to install R. In that case they cannot use conda or mamba, right? While there are certainly many R packages in conda-forge, it does not cover all packages in CRAN nor does it necessarily install the latest R versions.

[hermidalc]

Why spend effort to support another dependency manager that is limited to only R when conda has full R dependency management plus for other languages.

I believe many R users do not use conda to install R. In that case they cannot use conda or mamba, right? While there are certainly many R packages in conda-forge, it does not cover all packages in CRAN nor does it necessarily install the latest R versions.

You're not bound to use conda at all in VSCode... With vscode-python it searches and finds all interpreter/environment paths, including your system ones or other ones outside of conda. See my screenshot below after clicking Python: Select Interpreter. It shows all my python paths including my system ones and other ones outside of my conda envs.

This is exactly how vscode-R should work, so it continues providing the same support it already did for ppl who don't use conda and then also for people who do and who do it at the Github repo/project folder level.

[gwd666]

I am definitely sold on that feature extension. And props to the (two) main developers/maintainers here! That extension of yours is definitely a great addition the the R ecosystem imho not replacing RStudio but extending it to more types of use-cases. And tbh if it takes more than a couple of steps or iterations to get there -> also fine by me ... to me it looks like it will be worth the "wait"

[hermidalc]

Me too, will make VSCode really usable for me. And I will beta test whatever you need

[ElianHugh]

Thank you all for the feedback. We are a tiny repo in comparison to the python extension + don't have the resources of a full-time dev, so any and all help (be it feedback, testing, or dev work) is greatly appreciated.

[hermidalc]

I'm not experienced with doing VSCode extension dev work, but absolutely will do any testing and give detailed feedback on what you develop. We know how it should look and work because fortunately we can see it with vscode-python. Maybe connect with those devs to know how they did it, which they did very well. I know they use Pylance but I'm sure if you didn't have Pylance activated in your settings and in each of your folders connected to their respective conda environment (or system environment) you had python-lsp-server language server installed it could be set to use that, just like r-languageserver.

Atom couldn’t support a conda environment per project folder, which was a shame for developers that needed different environments per project it made things clunky because had to relaunch it in diff conda envs, but with Atom if you launched it from an activated conda env with python-lsp-server and r-languageserver installed and ide-python and ide-r Atom extensions installed it would work beautifully.

[ElianHugh]

Hi @ManuelHentschel,

At the moment the help server is spun up globally with a static path. If I was looking to have a separate help server per workspace folder (i.e. for multiroot), would it be viable to have a map of help servers rather than one global server?

[ManuelHentschel]

Hi @ManuelHentschel,

At the moment the help server is spun up globally with a static path. If I was looking to have a separate help server per workspace folder (i.e. for multiroot), would it be viable to have a map of help servers rather than one global server?

Yes that shouldn't be a problem. We could just have multiple instances of the classes in helpProvider.ts, and the methods RHelp.getHelpFileForPath etc. would need to be rewritten to use the correct providers (or e.g. try them all in order). If you like, I can implement this, just let me know your specific requirements.

[ElianHugh]

Absolutely, that would be fantastic! I'll try to setup a WIP PR for reference either tonight or tomorrow, just need to tidy up a bit first :)

[github-actions[bot]]

This issue is stale because it has been open for 365 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.