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

[William Dunlap]

You might make a second package that depends only on nimble and your
main package can then suggest that second package and JAGS.

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

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

[Bert Gunter]

>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

"The trouble with having an open mind is that people keep coming along and
sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )


On Wed, Aug 5, 2020 at 5:58 PM Lenth, Russell V 
wrote:

> Dear package developers,
>
> My package offers a few methods whose generics are in other packages; for
> example, 'cld', for which the generic is in the 'multcomp' package. Unless
> the user wants to use cld() (which I don't even encourage), they do not
> need the multcomp package to use other features of my package. Therefore, I
> do not want to import and re-export multcomp::cld. Instead, on loading my
> package, I dynamically register the method via RegisterS3Method() if the
> user's system happens to have multcomp installed; and if they don't, then
> they can still use my package, just not the cld method. this has worked
> well and keeps down the number of dependencies.
>
> The problem is documenting it. I thought I had it solved by using this
> roxygen2 tag:
>
> #' @method multcomp::cld emmGrid
>
> In turn, this tag generates these lines in the \usage section of my .Rd
> file:
>
> \method{multcomp::cld}{emmGrid}(object, details = FALSE, sort = TRUE,
> by,
>   alpha = 0.05, Letters = c("1234567890", LETTERS, letters),
>   reversed = FALSE, ...)
>
> and the resulting help file looks like this:
>
> ## S3 method for class 'emmGrid'
> multcomp::cld(object, details = FALSE, sort = TRUE, by,
>   alpha = 0.05, Letters = c("1234567890", LETTERS, letters),
>   reversed = FALSE, ...)
>
> This is exactly what I want. It tells the user clearly that if they want
> to use cld(), they have to have multcomp installed, and either name it
> explicitly in the call or have it in the search path.
>
> No problems occur until I check the package, when I get this warning
> message:
>
> Bad \usage lines found in documentation object 'summary.emmGrid':
>   method{multcomp::cld}{emmGrid}(object, details =
> FALSE, sort = TRUE, by,
> alpha = 0.05, Letters = c("1234567890", LETTERS, letters),
> reversed = FALSE, ...)
>
> Well I suppose this is "bad" as in unexpected; but it seems to be not bad
> in that it doesn't keep the help page from formatting correctly. And truly,
> I don't see how it could cause any harm. At lest the usage comes out
> correctly in both the HTML help and the PDF manual.
>
> I can avoid the problem just by omitting "multcomp::". But then the user
> doesn't get such a clear message about how to use the function.
>
> I'm interested in suggestions, but again I would regard importing
> multcomp::cld as an unhelpful suggestion. We ought to be able to provide
> courtesy methods for generics in other packages (and this is not the only
> one in my package) without importing a whole bunch of unneeded stuff and
> doubling the number of required installations.
>
> Thanks
>
> Russ
>
> Russell V. Lenth  -  Professor Emeritus
> Department of Statistics and Actuarial Science
> The University of Iowa  -  Iowa City, IA 52242  USA
> Voice (319)335-0712 (Dept. office)  -  FAX (319)335-3017
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] Documenting courtesy S3 methods

[Lenth, Russell V]

Dear package developers,

My package offers a few methods whose generics are in other packages; for 
example, 'cld', for which the generic is in the 'multcomp' package. Unless the 
user wants to use cld() (which I don't even encourage), they do not need the 
multcomp package to use other features of my package. Therefore, I do not want 
to import and re-export multcomp::cld. Instead, on loading my package, I 
dynamically register the method via RegisterS3Method() if the user's system 
happens to have multcomp installed; and if they don't, then they can still use 
my package, just not the cld method. this has worked well and keeps down the 
number of dependencies.

The problem is documenting it. I thought I had it solved by using this roxygen2 
tag:

#' @method multcomp::cld emmGrid

In turn, this tag generates these lines in the \usage section of my .Rd file:

\method{multcomp::cld}{emmGrid}(object, details = FALSE, sort = TRUE, by,
  alpha = 0.05, Letters = c("1234567890", LETTERS, letters),
  reversed = FALSE, ...)

and the resulting help file looks like this:

## S3 method for class 'emmGrid'
multcomp::cld(object, details = FALSE, sort = TRUE, by,
  alpha = 0.05, Letters = c("1234567890", LETTERS, letters),
  reversed = FALSE, ...)

This is exactly what I want. It tells the user clearly that if they want to use 
cld(), they have to have multcomp installed, and either name it explicitly in 
the call or have it in the search path.

No problems occur until I check the package, when I get this warning message:

Bad \usage lines found in documentation object 'summary.emmGrid':
  method{multcomp::cld}{emmGrid}(object, details = FALSE, 
sort = TRUE, by,
alpha = 0.05, Letters = c("1234567890", LETTERS, letters),
reversed = FALSE, ...)

Well I suppose this is "bad" as in unexpected; but it seems to be not bad in 
that it doesn't keep the help page from formatting correctly. And truly, I 
don't see how it could cause any harm. At lest the usage comes out correctly in 
both the HTML help and the PDF manual.

I can avoid the problem just by omitting "multcomp::". But then the user 
doesn't get such a clear message about how to use the function. 

I'm interested in suggestions, but again I would regard importing multcomp::cld 
as an unhelpful suggestion. We ought to be able to provide courtesy methods for 
generics in other packages (and this is not the only one in my package) without 
importing a whole bunch of unneeded stuff and doubling the number of required 
installations.

Thanks

Russ

Russell V. Lenth  -  Professor Emeritus
Department of Statistics and Actuarial Science   
The University of Iowa  -  Iowa City, IA 52242  USA   
Voice (319)335-0712 (Dept. office)  -  FAX (319)335-3017

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

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

[Dirk Eddelbuettel]

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

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

[Gaurav Sood]

I think the key line = " Unfortunately, nimble will not work with this
mechanism. "

Given that, depends seems like a good short-term solution. Change it to
suggests once the upstream problem is fixed.


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
>

[[alternative HTML version deleted]]

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

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

[Simon Bonner]

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