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.dun...@gmail.com] 
Sent: Saturday, 16 December 2017 10:18 PM
To: Chris Brien; r-package-devel@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


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

Reply via email to