In CRAN Repository Policy they write:
In principle, packages must pass R CMD check without warnings or significant notes to be admitted to the main CRAN package area.
The term "significant notes" appears a bit vague. Any idea what do they mean by this in practice? Or perhaps the question should be turned, what is an "insignificant note" in R CMD check allowing publication on CRAN?
I have a feeling that "significant notes" might be those they mention indirectly (package size and processing time of examples). I still feel a bit confused by this term. Hadley Wickham explains that each note has to be manually checked by a person and therefore notes should either be eliminated or mentioned in the submission comments. The whole point is to save the time of volunteers, which is "CRAN’s most precious resource", they write. Following this instruction, it would be nice to know which R CMD notes will definitely lead to the rejection of a package.
Related
I'm in the process of creating a small R package containing a set of functions that should be useful in a specialized area of Biology. I currently have the package on GitHub, but want to submit it to CRAN soon. One thing I have noticed when digging around in other packages, is that the code often includes no comments at all (e.g. short comments describing what different parts of the code does), which makes it more difficult to understand. I'm not a programmer or expert in R, so I don't understand why comments are often not included, and Hadley Wickham's "R packages" book makes not mention of this.
Edit: I'm not referring to the object documentation, that one accesses with ?function(), but to comments that are interspersed within the function code, which a normal user wouldn't see, but that could be helpful for people trying to figure out exactly how a function works.
Is there a specific reason to not include comments within the functions of an R package? If so, should I remove all the comments from my code before submitting to CRAN?
I am developing a package in R and when I run devtools::check() I am getting the following note.
checking DESCRIPTION meta-information ... NOTE
Malformed Description field: should contain one or more complete sentences.
I am not using my name of the package or the word package in the description. I am also using complete sentence for the description yet I am getting this NOTE repeatedly. So I am wondering what does a complete sentence mean in this case.
Try adding periods to the ends of the sentences, that is, turn your existing Description field into Functions to analyze methylation data can be found here. Highlight of this workflow is the comprehensive quality control report.
I've always found it a bit curious that the Description field shouldn't contain the word "package" or the name of the package ...and also requires complete sentences (which require both a subject and a verb, leading to very grammatically awkward constructs if you want your introductory sentence to have a subject without using the no-no words.) I'm pretty sure that grammatically speaking, very few packages have truly "complete" sentences in their Description fields.
I'm pretty sure that it just checks for capital letters and periods, and I'd avoid any special characters, just to be on the safe side.
The Description field of my package on CRAN is Reads river network shape files and computes network distances. Also included are a variety of computation and graphical tools designed for fisheries telemetry research, such as minimum home range, kernel density estimation, and clustering analysis using empirical k-functions with a bootstrap envelope. Tools are also provided for editing the river networks, meaning there is no reliance on external software. Definitely not the greatest, but apparently it worked and CRAN liked it!
Adding a full stop symbol/period/dot (.) at the end of the description details will remove this warning.
The R docs describe the ByteCompile field in the "DESCRIPTION file" section as:
The ‘ByteCompile’ logical field controls if the package code is to be byte-compiled on installation: the default is currently not to, so this may be useful for a package known to benefit particularly from byte-compilation (which can take quite a long time and increases the installed size of the package)
I infer the only detrimental side-effects to byte-compiling are (a) time-to-install and (b) installation size. I haven't found a package that takes too long during installation/byte-compiling, and the general consensus is that GBs are cheap (for storage).
Q: When should I choose to not byte-compile packages I write? (Does anybody have anecdotal or empirical limits beyond which they choose against it?)
Edit: As noted in the comments of an older question, the rationale that debugging is not possible with byte-compiled code has been debunked. Other related questions on SO have discussed how to do it (either manually with R CMD INSTALL --byte-compile ... or with install.packages(..., type="source", INSTALL_opts="--byte-compile")), but have not discussed the ramifications of or arguments against doing so.
I have yet to find a downside for byte-compiling, other than the ones you mention: slightly increased file size and installation time.
In the past, compiling certain code could cause slow-down but in recent versions of R (version >3.3.0), this doesn't seem to be a problem.
Can I use pairwise.wilcox.test() for post hoc test as my friedman.test() gat sifnificant?
I can't install pgirmass for the friedmanmc() function as its not compatible with my R version.
Does pairwise.wilcox.test() make sense for more than two samples?
Thank you for your help!
You haven't offered a specific example or an explanation of the the study design and hypotheses being tested, but the documentation does say that "corrections for multiple testing" are made, so you should be reasonably safe on statistical grounds. (There is some debate about the need for multiple comparisons tests.)
On the topic of the other package, you are misspelling its name and there is a current version available from CRAN for pkg:pgirmess. After reading the documentation of the two tests, I would probably trust the pairwise.wilcox.test more than the friedmanmc test because it is in a core R package, while the friedmanmc test appears to have undesireable behavior that gets suppressed in an awkward fashion, leading me to think it uses something of a statistical hack. I'm not encouraging you to do so but if your unstated R version is somewhat older, there may be suitable package versions, since I see versions going back to 2005 in the Archives.
I'm looking for a an R package which can be used to train a Dirichlet prior from counts data. I'm asking for a colleague who's using R, and don't use it myself, so I'm not too sure how to look for packages. It's a bit hard to search for, because "R" is such a nonspecific search string. There doesn't seem to be anything on CRAN, but are there any other places to look?
I've only come across both R and the Dirichlet distribution in passing, so I hope I'm not too much off the mark.
This mailing list message seems to answer your question:
Scrolling through the results of
RSiteSearch("dirichlet") suggests some useful tools
in the VGAM package. The gtools package and
MCMC packages also have ddirichlet() functions
that you could use to construct a (negative log) likelihood
function and optimize with optim/nlmin/etc.
The deal, DPpackage and mix packages also may or may not provide what you need.
Then again, these are all still CRAN packages, so I'm not sure if you already found these and found them unsuitable.
As for searching for R, the R project site itself already provides a few links on its search page.