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

______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Reply via email to