fslaborg / RProvider

Access R packages from F#
http://fslab.org/RProvider/
Other
235 stars 69 forks source link

Roadmap for RProvider - please share your experiences and ideas #266

Open AndrewIOM opened 2 months ago

AndrewIOM commented 2 months ago

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:

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).

AndrewIOM commented 2 months ago

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.