Roadmap for RProvider - please share your experiences and ideas

[AndrewIOM]

Is your feature request related to a problem? Please describe.
For planning the next feature release of RProvider, I thought it appropriate to start a thread here where those interested can contribute to a discussion on key features or ideas to potentially take forward to the next release, or link to key outstanding issues. Some key questions are:

• are people using RProvider in day-to-day work, or if not why it is not a viable option and how could it be improved?
• are there more modern alternatives that work better, and if so why?
• are there interoperability issues with the wider fsharp ecosystem?

Dependency on R.NET + DynamicInterop
Some of our outstanding bugs and issues arise from within R.NET, which is not currently very active as a project (see: rdotnet/rdotnet#158). I have submitted a PR to update the build tools and process for R.NET at rdotnet/rdotnet#159 and hope that this can be merged. From there, we should be able to better test bugs and send in PRs to address issues in RProvider.

Milestone
I've made a milestone to collect together important issues for a next release (see attached milestone).

[AndrewIOM]

I can start by adding a quick thought from my position as a scientist.

RProvider works very well in scripting on macos with visual studio code, but my key concern is reproducibility. I cannot easily use RProvider for work that is to be peer-reviewed because it uses the global R version, environment and packages. Ideally, I would like some kind of optional package definition and lock file (maybe with an auto-restore) that lives in the same location as an RProvider fsproj or script file.

I often use RProvider for making charts of dotnet data projects, for example using ggplot. However, the Quartz or X11 interfaces for this are a bit wonky and hard to work with. A better / more stable way of working with graphics would help.