Datashield R API

Support Developer support
30

Hi Olly,

I have created a DSI branch for all of these DataSHIELD packages:

  • dsBetaTestClient
  • dsBetaTest
  • dsBaseClient
  • dsBase
  • dsGraphicsClient
  • dsModellingClient
  • dsModelling
  • dsMxClient
  • dsStatsClient

There are changes in server side packages as well, which I did not expect, but these are only required for DSLite because when using environment-dependent functions like eval, get, assign and as.formula, one must specify in which environment the symbols are to be looked for or assigned to. By default it ends in the Global Env but with DSLite, there is no Global Env for the server side execution environment (because the Global Env is the client side and we do not want them to overlap). For instance dsBetaTest is using a lot of eval() calls. The modification is easy though (adding parameter envir = parent.frame()).

Then if you want to give it a try, install both client and server sides packages from the DSI branch (there is not necessarily one for the server side). All the testthat tests are passing successfully.

In other words, the DSI migration is done at 90%, what remains to be done is testing with your pipeline.

For the end users, the only changes I expect are:

  • installing DSOpal (with dependencies DSI and opalr) on client side
  • adding library(DSOpal) at the beginning (and removing library(opal))
  • for the ones using the opal-specific functions that have been added in dsBetaTestClient, replace by the corresponding DSI functions (the ones starting with DSI::datashield.connections* for instance).

Once I have your feedback and OK, I can start the submission of the DSI, DSOpal and DSLite packages in the official CRAN. This can be done before the datashield analysis packages are ready. I have already gone through the CRAN submission procedure for opalr, they are quite picky regarding the quality of the packaging, approval can take several weeks, but it’s worth the effort in terms of visibility and credibility.

Cheers
Yannick