[R-pkg-devel] Large data package

Duncan Murdoch murdoch@dunc@n @end|ng |rom gm@||@com
Sun May 2 16:29:05 CEST 2021

On 02/05/2021 8:44 a.m., Dirk Eddelbuettel wrote:
> On 2 May 2021 at 10:12, Ayala Hernandez, Rafael wrote:
> | Following Dirk's suggestion below, I have recently added a data package as a drat repository for my asteRisk package, placing it under Suggests in the main package.
> | In order to keep the code tidy and know exactly when I’m accessing the data in the data package, I access all the data in the data package as asteRiskData:::Item
> Why would that be 'tidy'?
> Just use two colons as usual for things exported from your data package, and
> export everythng that your code package uses from it. The ':::' idiom is not
> to be used across package, ie don;t use in package B to access content from
> A. Which is what R CMD check is telling your here: "don't do this".

I wouldn't call it "tidy", but there are some possible reasons to do 
this.  One may apply here:

  - You may not want other packages to depend on the data, because you 
would like to be able to change it without notice.  Normally you'd do 
this by making it a private part of the main package, but if it's really 
big, that's discouraged.  So the use described here may be reasonable.

I can't spot it in the docs right now, but I believe CRAN will allow the 
use of ::: if the package it is importing from has the same maintainer 
as the main package.

The problem here is that CRAN doesn't know who is the maintainer for 
asteRiskData.  That package is not on CRAN, and they don't look on other 
repositories to figure it out.

So the answer to Rafael's original question is that I think CRAN would 
agree to this use if you have a good reason for it, but you'll need to 
explain that reason in your submission message, and it will need manual 
intervention to ignore the automatic rejection.

Following Dirk's advice is thus advisable (passing the auto checks is 
better than requiring manual intervention on every update), but not 
strictly necessary.

Duncan Murdoch

More information about the R-package-devel mailing list