fslaborg
Roadmap for RProvider - please share your experiences and ideas
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: https://github.com/rdotnet/rdotnet/issues/158). I have submitted a PR to update the build tools and process for R.NET at https://github.com/rdotnet/rdotnet/pull/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).
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.