[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