search

Mouse-Imaging-Centre / RMINC

Statistics for MINC volumes: A library to integrate voxel-based statistics for MINC volumes into the R environment. Supports getting and writing of MINC volumes, running voxel-wise linear models, correlations, etc.; correcting for multiple comparisons using the False Discovery Rate, and more. With contributions from Jason Lerch, Chris Hammill, Jim Nikelski and Matthijs van Eede. Some additional information can be found here:
https://mouse-imaging-centre.github.io/RMINC
Other
22 stars 17 forks source link

Remaining check notes to address (+ proposed solutions) #63

Closed cfhammill closed 8 years ago

cfhammill commented 8 years ago

RMINC is now warnings free with R CMD check --as-cran, technically we now stand a chance of being accepted on CRAN, however, our odds increase if we can reduce the number of notes we have. There are five remaining notes to address

1: Checking installed package size is 95.8Mb, sub-directories of 1Mb or more doc, libs, packageData

I'm not sure we can fix this one, the libs directory contains RMINC.so only and I'm uncertain how to reduce its size. PackageData contains files used to generate the documentation, it may not be possible to reduce this significantly unless we took the approach of autogenerating the data from within R. We could also in principle create a data package, then RMINC can depend on that.

2: Deprecated license BSD

We could potentially switch to another OSS license like MIT or Artistic, but I'm uncertain the legalities of trying to change licenses. Probably best to leave this one as is.

3: Non-standard directories in top level: "releases"

This could either be moved to /inst, added to .Rbuildignore, or deleted outright. I lean toward the latter two, if our releases are tagged on github there is no reason I can see to maintain them in the source. Additionally once RMINC reaches CRAN, all future releases will be archived by CRAN.

4: Unexported objects lme4:::RHSform etc. etc.

I think we should leave this one as is as well. The alternative would be to copy the source code from lme4 and lmerTest into our code but this may prove problematic if it has nested dependencies on other internals, or worse yet on compiled code.

5: Vignette sources only in inst/doc

As of recent R's vignette sources are supposed to be located in vignettes/, the pdfs and sweave files could be moved to another directory in inst/ e.g. inst/documentation, or in the long run a better solution would be to rejig the vignettes so that they can be run and knit at build time, the problem ends up being the same as for packageData in NOTE 1, how do we robustly supply testing data without angering CRAN.

So even can comfortably fix 3 and 5. We can fix 2 if someone understands these licenses well enough. We can fix 1 and 5 with a significant time investment, but would yield the added benefit of making our testing system less reliant on external data, I'm going to follow this idea up in the next issue.

cfhammill commented 8 years ago

No one has weighed in so I will proceed with removing releases, these are better handled through CRAN and github (easily reversible if we later decide they belong in the package). And I will rename inst/doc to inst/documentation until they can be automatically regenerated.

mcvaneede commented 8 years ago

I agree, given that we use GitHub, there's really no need for the releases directory any more. In terms of the data, do you see any benefit of using our repo/wiki versus a data package?

cfhammill commented 8 years ago

I think given the nature of our data, hosting a test data set that can be downloaded is probably the best approach. A data set package would be more beneficial if our data was large R objects as opposed to files.