Repository navigation
Create or provide choice for multiple R versions and x64 or i386 architectures for R terminal #696
Description
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!
Activity
renkun-ken commentedon Jul 5, 2021
Have you tried typing in the terminal to start R-x64 and R-i386 terminal and do both work?
gwd666 commentedon Jul 5, 2021
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 definingRtermpath in the R extensionSettingsyou would also have to decide theARCH- 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 theR: Create R terminalcommand, 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 commentedon Jul 5, 2021
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 commentedon Jul 5, 2021
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 #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.xxxandr.term.xxxat all, and simply have the version I'm currently using on the PATH. Or if the R path is project specific, using thesettings.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:
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 commentedon Jul 5, 2021
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 commentedon Jul 5, 2021
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 commentedon Jul 5, 2021
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 commentedon Jul 5, 2021
If multiple paths are specified in
r.path.xxx, then starting background processes (e.g. R help, language server) should prompt?ManuelHentschel commentedon Jul 6, 2021
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.xxxbe 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 commentedon Jul 6, 2021
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 commentedon Jul 6, 2021
I was thinking about exactly the same thing as @ElianHugh suggests.
gwd666 commentedon Jul 6, 2021
@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
[-]Create or provide choice for x64 or i386 R terminal (for Windows) [/-][+]Create or provide choice for multiple R version and x64 or i386 architectures for R terminal[/+][-]Create or provide choice for multiple R version and x64 or i386 architectures for R terminal[/-][+]Create or provide choice for multiple R versions and x64 or i386 architectures for R terminal[/+]23 remaining items
hermidalc commentedon Jun 29, 2022
Because
renvis an R ecosystem only dependency manager.mamba/condaandconda-forgeare 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 usingsnakemakeandrpy2in 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 commentedon Jun 29, 2022
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 commentedon Jun 29, 2022
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 commentedon Jun 29, 2022
You're not bound to use conda at all in VSCode... With
vscode-pythonit searches and finds all interpreter/environment paths, including your system ones or other ones outside of conda. See my screenshot below after clickingPython: 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-Rshould 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 commentedon Jun 29, 2022
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 commentedon Jun 29, 2022
Me too, will make VSCode really usable for me. And I will beta test whatever you need
ElianHugh commentedon Jun 30, 2022
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 commentedon Jun 30, 2022
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-serverlanguage server installed it could be set to use that, just liker-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-serverandr-languageserverinstalled andide-pythonandide-rAtom extensions installed it would work beautifully.ElianHugh commentedon Jul 2, 2022
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 commentedon Jul 2, 2022
Yes that shouldn't be a problem. We could just have multiple instances of the classes in helpProvider.ts, and the methods
RHelp.getHelpFileForPathetc. 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 commentedon Jul 3, 2022
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 commentedon Jul 10, 2023
This issue is stale because it has been open for 365 days with no activity.
github-actions commentedon Jul 25, 2023
This issue was closed because it has been inactive for 14 days since being marked as stale.