[R-pkg-devel] Problem enhancing a package with a predict method not declared to be an S3 method

[Chris Brien]

Hi Duncan,

Thanks for your comments. I appreciate that you do not speak for CRAN. 

I had thought that, while I am accessing asreml internals, I do not believe that it is the intention of the maintainer that they be internal. Indeed, I am only calling functions documented in the manual and so it would appear that they are intended to be part of the API for the packages. I had hoped that this would be an allowed exception.

Nonetheless, I am attempting to contact the maintainer and I will see what that brings.

Regards,

  Chris


-----Original Message-----
From: Duncan Murdoch [mailto:murdoch.duncan at gmail.com] 
Sent: Saturday, 16 December 2017 10:18 PM
To: Chris Brien; r-package-devel at r-project.org
Subject: Re: [R-pkg-devel] Problem enhancing a package with a predict method not declared to be an S3 method

On 15/12/2017 11:52 PM, Chris Brien wrote:
> Dear list members,
> 
> I am in a bind.
> 
> I have a package asremlPlus that "Enhances" the commercial package asreml (and asreml4), for which I am not a maintainer. It is not available in a public repository and because of this, when checking it for CRAN, it always gives the following NOTE, which is acceptable to CRAN:
> 
> Suggests or Enhances not in mainstream repositories:
>    asreml, asreml4
> 
> Now asreml has three functions summary.asreml, fitted.asreml and predict.asreml that are (i) not exported and (ii) not declared to be S3 methods. In spite of this it is possible to call them using summary, fitted and predict.
> 
> However, if I do this in the code then the suite of unit tests that I have for asremlPlus fails when run with testthat::test_check with the following Error:
> 
>  [31m1. Error: predictPlus.asreml (@testPredictionsPresentation.r#17) 
>  [39m--------------- could not find function "ie"
> 1: predictPlus.asreml(classify = "Sources:Type", asreml.obj = 
> current.asr, tables = "none", wald.tab = current.asrt$wald.tab, 
> present = c("Type", "Species", "Sources")) at 
> testthat/testPredictionsPresentation.r:17
> 2: predict(asreml.obj, classify = classify, sed = pairwise, trace = 
> trace, ...)
> 3: predict.asreml(asreml.obj, classify = classify, sed = pairwise, 
> trace = trace, ...)
> 
> On the other hand, the test completes successfully if I manually execute it line-by-line, but this is not feasible in practice because there are 21 sets of tests.
> 
> The manifest problem is "ie", which is another unexported function in asreml, apparently called by predict.asreml.
> Has anyone on this list advice to offer on how this problem might be overcome?
> 
> Any help gratefully received,
> 
> Chris Brien, University of South Australia
> 
> PS I know that the problem can be avoided by calling the functions 
> within asremlPlus using asreml:::, but this appears to be unacceptable 
> to CRAN because it produces the NOTE
> 
> Unavailable namespaces imported from by ':::' calls:
>    'asreml' 'asreml4'
>    See the note in ?`:::` about the use of this operator.
> 
> And the NOTE in ?':::' says
> 
> It is typically a design mistake to use ::: in your code since the corresponding object has probably been kept internal for a good reason. Consider contacting the package maintainer if you feel the need to access the object for anything but mere inspection.

I don't speak for CRAN, but I think it is consistent with their philosophy that a package doing what yours does should not be allowed there.

Your package depends on the internals of asreml.  There is nothing to stop that package from changing them, causing your package to generate errors or incorrect results.  CRAN does what it can to prevent this kind of error, and it can't do it with yours.

I'd suggest that you contact the maintainers of asreml, and ask them to export the functions you need.  If they are unwilling to do that, then you could ask them to distribute your package, or distribute it yourself (e.g. by making it available on Github).

One other possibility is that their license would allow you to copy enough of their package into yours that you wouldn't need the ::: 
import, but that seems unlikely.

Duncan Murdoch