Closed PavelBal closed 4 years ago
@msevestre , @Yuri05 , @PavelBal As we will want to use the R-toolbox and R-reporting engine in a GxP validated environment all packages that are being used will have to be validated packages. Our standard way (and frankly, I believe this is the only practicable way) is to use a validated R distribution (ValidR of a company called Mango in our case). It is of primary importance that packages that you are going to use are either part of the validR distribution (I'm happy to provide a pdf document with a list if someone tells me where to put it) or have to be validated as quickly as possible. For the latter to actually happen we would need a list of additional (as in "not part of validR) packages as quickly as possible.
The R6 packaged for instance is part of the distribution but is flagged as "not validated". We will have to figure out what the implications of that are ...
rClr ist most probably not validated, but is the key of all our implementations. This is going to be tricky - how can a package be "validated"?
@PavelBal. Good point. In the end we will have to find a way for packages that are crucial to the implementation and not part of validR. Really, the most important bit is that we know about these packages as early as possible. We can then think about how to get them validated.
@DiedrichC For the TLF lib, it was requested to use the well known dplyr
package which is fantastic to manipulate data.
Can you check to see if this is a validated package? Obviously we are also using ggplot
@DiedrichC any feedback here? How can we see the list of approved packages? This is crucial that we get an answer soon here as this is blocking
@msevestre and @Yuri05 dplyr is part of validR. btw: We are currently almost exclusively using data.table rather than dplyr. It is MUCH faster and hence a better choice if you are dealing with very large data frames (or rather data.tables).
@DiedrichC ok. Does it provides easy selection methods (filtering, grouping etc..)? I was under the impression that dplyr was more of a toolset to work with data.frame as opposed to a replacement from data.frame.
Would you suggest that we only work with data.table instead of data.frame? FYI: @Yuri05
@msevestre As both packages are part of validR I don't see any problems with using both. Data.table is compatible with data.frame. Rolling joins in data.tables are nice. But dont think that you really need them. Performance is irrelevant given the smallish data.frames that you are going to deal with.
Here the list of all packages that will be in Valid R 3.5.2 and which version acepack | 1.4.1 ade4 | 1.7-13 affy | 1.60.0 amap | 0.8-16 base | 3.5.2 BH | 1.69.0-1 binom | 1.1-1 bitops | 1.0-6 boot | 1.3-20 broom | 0.5.1 Cairo | 1.5-9 calibrate | 1.7.2 caret | 6.0-81 caTools | 1.17.1.1 chemometrics | 1.4.2 class | 7.3-14 cluster | 2.0.7-1 coda | 0.19-2 codetools | 0.2-16 colorspace | 1.3-2 combinat | 0.0-8 compiler | 3.5.2 covr | 3.2.1 coxphf | 1,13 coxrobust | 1 cvTools | 0.3.2 data.table | 1.11.8 datasets | 3.5.2 deSolve | 1,21 devEMF | 3.6-2 devtools | 2.0.1 dichromat | 2.0-0 digest | 0.6.18 doBy | 4.6-2 doParallel | 1.0.14 DoseFinding | 0.9-16 dplyr | 0.7.8 drc | 3.0-1 DT | 0,5 evaluate | 0,12 ezknitr | 0,6 FactoMineR | 1,41 fields | 09.01.1900 flexsurv | 1,1 forcats | 0.3.0 foreach | 1.4.4 foreign | 0.8-71 formatR | 1,5 Formula | 1.2-3 fpc | 2.1-11.1 gam | 1,16 ggplot2 | 3.1.0 glmnet | 2.0-16 gmodels | 2.18.1 goodpractice | 1.0.2 GPArotation | 2014.11-1 graphics | 3.5.2 grDevices | 3.5.2 grid | 3.5.2 gridExtra | 2,3 gtable | 0.2.0 haven | 2.0.0 Hmisc | 4.1-1 htmlTable | 1.13.1 htmltools | 0.3.6 httr | 1.4.0 iptools | 0.6.1 iterators | 1.0.10 itertools | 0.1-3 KernSmooth | 2.23-15 knitr | 1,21 labeling | 0,3 lattice | 0.20-38 latticeExtra | 0.6-28 lazyeval | 0.2.1 limma | 3.38.2 lintr | 1.0.3 lme4 | 1.1-19 lmerTest | 3.0-1 logistf | 1,23 lsmeans | 2.30-0 lubridate | 1.7.4 magrittr | 01.01.1900 mangoTraining | 1.0-7 MASS | 7.3-51.1 Matrix | 1.2-15 mclust | 5.4.2 MCMCpack | 1.4-4 metafor | 2.0-0 methods | 3.5.2 mgcv | 1.8-26 minpack.lm | 1.2-1 mlr | 02.01.1900 mnormt | 1.5-5 MSToolkit | 3.2.4 multcompView | 0.1-7 munsell | 0.5.0 mvtnorm | 1.0-8 ncappc | 0.3.0 nlme | 3.1-137 nlmeODE | 01.01.1900 nnet | 7.3-12 npde | 02.01.1900 numDeriv | 2016.8-1 odeintr | 1.7.1 officer | 0.3.2 openxlsx | 4.1.0 parallel | 3.5.2 pcaMethods | 1.74.0 penalized | 0.9-51 PK | 1.3-4 PKPDmodels | 0.3.2 plot3D | 1.1.1 plotrix | 3.7-4 plsdepot | 0.1.17 plsgenomics | 1.5-2 plspm | 0.4.9 plyr | 1.8.4 png | 0.1-7 PopED | 0.4.0 prettyR | 2.2-2 pROC | 1.13.0 prodlim | 2018.04.18 proto | 1.0.0 pspline | 1.0-18 psych | 1.8.10 purrr | 0.2.5 qvalue | 2.14.0 randomForest | 4.6-14 raster | 2.8-4 RColorBrewer | 1.1-2 Rcpp | 1.0.0 readr | 1.3.1 readxl | 1.2.0 ReporteRs | 0.8.10 reshape | 0.8.8 reshape2 | 1.4.3 rmarkdown | 1,11 rmdshower | 2.1.1 Rmisc | 01.01.1900 Rmpi | 0.6-9 rms | 5.1-2 RNMGraphics | 4.0-7 RNMImport | 4.0-32 robust | 0.4-18 ROCR | 1.0-7 rpart | 4.1-13 rstan | 2.18.2 rtf | 0.4-13 rvest | 0.3.2 SASxport | 1.6.0 scales | 1.0.0 shape | 1.4.4 shiny | 1.2.0 shinydashboard | 0.7.1 spatial | 7.3-11 splines | 3.5.2 stargazer | 5.2.2 stats | 3.5.2 stats4 | 3.5.2 stringi | 1.2.4 stringr | 1.3.1 survival | 2.43-3 tables | 0.8.7 tcltk | 3.5.2 testthat | 2.0.1 tibble | 2.0.0 tidyr | 0.8.2 tm | 0.7-6 tools | 3.5.2 ucminf | 1.1-4 utils | 3.5.2 VGAM | 1.0-6 viridis | 0.5.1 vpc | 1.1.0 vrwatch | 1.0.1 xlsx | 0.6.1 xpose4 | 4.6.1 yaml | 2.2.0
@PavelBal Please update Readme with instructions.
How are the users supposed to install rClr? Do they have to download the .zip (under Windows) and install manually?
yes. We will add the package to the release page . It will have to be installed using install.packages. No way around this
How about Linux?
Under Linux: rClr will have to be installed from Source. We may provide two packages "CentOS" and "unbuntu" to be installed.
ospsuite. We will provide CentOS and Ubuntu packages as well. Compiling from source won't be possible for now
@Yuri05 Please correct me if I am wrong
@msevestre Correct
(rClr for Ubuntu will become .tar.gz as well; zips are not accepted by install.packages)
Also based on my last experience I would not use devtools but only install.packages under Linux:
I have updated the README.
I have updated the README.
tlf is not a prereq for ospsuite?
not yet. We do not use it so far. We wanted to implement some default plots but this was not specified
As our package will not be on CRAN (at least not at the beginning), the user has to manually install all packages that are not in
base
. We will have to list it in thereadme
.For now these are: