Re: [R-pkg-devel] Package can't be imported with Suggests

[Dr . Jens Oehlschlägel]

Dirk,

This sounds familiar: in package 'bit' for  

bit | bitwhich 

R did neither S3-dispatch to "|.bit" nor to "|.bitwhich" but nonsensically to 
the default method. 

It took me a while to reverse my class thinking enough to realize that I could 
get control by forcing dispatch to a common class 'booltype'.  So far this 
sounds harmless. But the truth is that to make this work 'booltype' must not be 
a common superclass but needs to be a subclass of 'bit' in bit-objects and 
needs to be a subclass of 'bitwhich' in bitwhich-objects. Only then the 
dispatch to "|.booltype" dominates and we get a seemingly conflict-free 
dispatch to "|.booltype" which then resolves possible conflicts. I hope using 
R's S3 class system upside-down does not introduce "another problem". Citing 
from "Beautiful Code":

"
it is worth bringing our discussion to an end by noting that Lampson attributes 
the aphorism that started our exploration (all problems in computer science can 
be solved by another level of indirection) to David Wheeler, the inventor of 
the subroutine. Significantly, Wheeler completed his quote with another phrase: 
"But that usually will create another problem."
"

Best

Jens



#
> Gesendet: Donnerstag, 06. August 2020 um 01:30 Uhr
> Von: "Dirk Eddelbuettel" 
> An: "William Dunlap" 
> Cc: "r-package-devel@r-project.org" 
> Betreff: Re: [R-pkg-devel] Package can't be imported with Suggests
>
> 
> On 5 August 2020 at 16:25, William Dunlap wrote:
> | You might make a second package that depends only on nimble and your
> | main package can then suggest that second package and JAGS.
> 
> Nice. "We can solve any problem by introducing an extra level of indirection."
> 
> See https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering
> 
> Dirk
>  
> | Bill Dunlap
> | TIBCO Software
> | wdunlap tibco.com
> | 
> | On Wed, Aug 5, 2020 at 3:36 PM Simon Bonner  wrote:
> | >
> | > Hi all,
> | >
> | > I’m wondering if someone an offer advice on a problem I’m facing in 
> developing a package.
> | >
> | > My package essentially generates code and formats data for one of two 
> MCMC sampling engines, JAGS accessed via rjags or nimble (a native R 
> package), calls the engines, and then provides functions to access the 
> results. Since only one of the engines is needed I would like to include 
> rjags and nimble in Suggests in the DESCRIPTION and use requireNamespace() to 
> load the appropriate package when its functionality is needed.
> | >
> | > Unfortunately, nimble will not work with this mechanism. It relies on a 
> complex mechanism to compile C++ code to run the sampler, and some of the 
> functions cannot be found when the package is loaded in this way. I’ve been 
> in touch with the maintainers and they are aware of the issue but the current 
> fix is to include the package under Depends. However, this forces a user to 
> install nimble (which itself requires compiling lengthy C++ code) even if the 
> user intends to run the sampler in JAGS.
> | >
> | > I thought I’d solved the problem by including nimble in Suggests and then 
> loading it via library() so that all of its functions are attached. This 
> works, but produces a note during the check:
> | > ❯ checking dependencies in R code ... NOTE
> | >   'library' or 'require' call to ‘nimble’ in package code.
> | > Please use :: or requireNamespace() instead.
> | > See section 'Suggested packages' in the 'Writing R Extensions' manual
> | >
> | > What is the recommendation?
> | >
> | > I see two options:
> | >
> | >
> | >   1.  Include nimble in Depends and force user to install it.
> | >   2.  Ignore the note and explain the problem when I resubmit to CRAN.
> | >
> | > Am I missing anything?
> | >
> | > Thanks in advance!
> | >
> | > Simon
> | >
> | >
> | >
> | >
> | >
> | > Simon Bonner
> | > Assistant Professor of Environmetrics
> | > Department of Statistical and Actuarial Sciences
> | > University of Western Ontario
> | >
> | > Office: Western Science Centre rm 276
> | >
> | > Email: sbonn...@uwo.ca | Telephone: 519-661-2111 
> x88205 | Fax: 519-661-3813
> | > Twitter: @bonnerstatslab | Website: 
> http://simon.bonners.ca/bonner-lab/wpblog/
> | >
> | >
> | > [[alternative HTML version deleted]]
> | >
> | > __
> | > R-package-devel@r-project.org mailing list
> | > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> | 
> | __
> | R-package-devel@r-project.org mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> -- 
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] Documenting courtesy S3 methods

[Lenth, Russell V]

Thanks, Bert. 

This looks potentially useful as an alternative to the way I currently 
dynamically register the method. It does seem to require that 'pkg' must 
actually be installed on the system in order to work, and that pkg would have 
to be listed in Import. I'd rather not force users to install packages they 
will never use. I am not sure of this requirement, but I'm sure I could verify 
it one way or the other using the checking system.

And yes, I could (and do) document within the Details and Examples (and could 
add a note as well) that users need to use multcomp::cld(). It just seems that 
actually showing that in the Usage section is by far the clearest way to 
communicate that requirement.

Russ

From: Bert Gunter  
Sent: Wednesday, August 5, 2020 9:31 PM
To: Lenth, Russell V 
Cc: r-package-devel@r-project.org
Subject: [External] Re: [R-pkg-devel] Documenting courtesy S3 methods

From WRE:

"As from R 3.6.0 one can also use S3method() directives to perform delayed 
registration. With
if(getRversion() >= "3.6.0") {
S3method(pkg::gen, cls)
}
function gen.cls will get registered as an S3 method for class cls and generic 
gen from package pkg only when the namespace of pkg is loaded. This can be 
employed to deal with situations where the method is not “immediately” needed, 
and having to pre-load the namespace of pkg (and all its strong dependencies) 
in order to perform immediate registration is considered too onerous."
I understand the issue is documentation, but if you took this route, could you 
not document your S3 method as usual without loading multcomp's (or whatever) 
namespace. You could include a \note section in the doc saying that the 
multcomp namespace must be explicitly loaded if your method is to be used 
(perhaps showing the code to do so)
If I am clearly mistaken about this, feel free to dismiss without reply.

Cheers,
Bert Gunter


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

Re: [R-pkg-devel] Documenting courtesy S3 methods

[Lenth, Russell V]

Testing results for Bert's suggestion...

I tested this with a different -- much smaller -- package: Put the S3method() 
construct in NAMESPACE but the generic package is not mentioned at all in any 
DESCRIPTION field. I built the package and checked it --as-cran. Interesting 
results:

  * Calling multcomp::cld(object) worked just fine without my doing anything to 
register the method. 
  * In checking, there was no objection to my not importing the generic for cld.

So this looks like a potentially good solution, except for the documentation 
issue.

BTW, note this parallel:

  * In NAMESPACE, the constructS3method(pkg::gen, cls)
  * In Rd files, the macro\S3method{pkg::gen}{cls}(args)

The latter is what I am asking about, that creates a warning. However, the 
parallel between these just cries out to be valid!

Russ

From: Bert Gunter  
Sent: Thursday, August 6, 2020 12:22 PM
To: Lenth, Russell V 
Subject: Re: [R-pkg-devel] Documenting courtesy S3 methods

Probably unnecessary to say, but if/when you determine whether the package must 
be installed, let us all know.

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