Wow, this'll be interesting to follow: _R_CHECK_EXCESSIVE_IMPORTS_: …nbr of imports from non-base packages exceed this threshold. Large numbers of imports make a package vulnerable to any of them becoming unavailable. Default: unset (but 20 for CRAN submission checks) #rstats
6
8
6
36
"Becoming available" is an interesting choice of words, given the reasons that some packages have been removed from CRAN recently. This and the new orphaned checks point to CRAN wanting to be less persistent and less comprehensive, which is a shame.
2
5
I am to blame for the orphaned pkg thing. I asked for some packages to be removed or orphaned from cran (the cloudyr stuff) and got yelled at about it by a certain person. I apologize to the #rstats community for the policy reaction to it, which will now make our lives harder.
2
1
4
That seems like a legit use of orphaning. I know of several orphaned because of a request to make the package compile with gcc10 over the Christmas break. gcc10 is not available on any linux distribution at the moment, and must be compiled from source.
2
1
Replying to @rgfitzjohn @thosjleeper @henrikbengtsson
That comment is not helpful, and not true or relevant for the gcc10 email I got from CRAN. Which clearly said that a now-optional check (available under gcc9, easy to enable, it showed how) will be mandatory in gcc10. Hence the suggestion to fix now before things break for real.

Jan 27, 2020 · 2:02 AM UTC
1