[R-pkg-devel] [FORGED] Re: How to (conditionally) use an archived package (without Suggests)?

[Marius Hofert]

On Sun, Feb 25, 2018 at 11:16 AM, Rolf Turner <r.turner at auckland.ac.nz> wrote:
>
> Marius:
>
> Can you not, instead of
>
>> if(pkg == "loon" && !requireNamespace("loon", quietly = TRUE))
>>         stop("Package 'loon' is not available.")
>
> do something like:
>
> if(pkg == "loon" && !requireNamespace("loon", quietly = TRUE)) {
>          cat("Package 'loon' is not available.\n")
>          cat("Sorry 'bout that, chief!\n")
>          return(invisible())
> }
>

Hi,

... of course I can do that, but I don't see how that solves the
problem: This part of the code is not even executed until the user
actively calls the surrounding function (zenplot()) with the method
that uses loon (not the default obviously). As such, the whole package
perfectly works (even if you don't have loon) *except* for the check
(--as-cran) to give me the warning:
* checking dependencies in R code ... WARNING
'::' or ':::' import not declared from: ‘loon’
'loadNamespace' or 'requireNamespace' call not declared from: ‘loon’
... and putting 'loon' in Suggests (to avoid this warning) does not
seem to be allowed as 'loon' is not on CRAN.

Again: The rest of the check and the package works (whether you have
loon installed or not), only if you actively want to use loon and you
don't have loon installed, then you'll see the error (which is
conceptually correct because you don't have loon installed).

This also means that I can easily solve the problem by simply removing
the whole dependence on loon from zenplots (as a 'plan B'), but that
would take away this feature completely which is somewhat sad (we
wrote a lot of functions to provide support for dynamic graphics with
loon).
I will probably even do that, but at the moment I'm just interested in
the problem in itself (you know, as an academic, you tend to get
fascinated by certain problems... kind of an 'occupational
disease'...).
Just imagine there is no solution to this problem. Let A be a package
(of which you are the maintainer) which depends on another package B
(of which you are not the maintainer) -- but code of B is actually
only used under very specific circumstances. If B suddenly disappears
from CRAN, A will be archived, too, although in 99% of the cases, A
doesn't even use B... that would be a bit scary (?), especially as you
(as maintainer of A) have no control over what the maintainer of B
does. It seems advisable in these situations to omit the dependence on
B at all, but B here adds a lot of features (dynamic plotting) which
cannot easily be incorporated otherwise.

> Thereby no error is thrown.  The user may be unhappy with the result,
> but he or she would have been similarly unhappy with the error, and
> there is no way of constructing your function so that such a user *will*
> be happy.

The error is not the problem (this is not why the package is not
accepted for submission to CRAN as the error only shows up of you
actively call zenplot() with the corresponding method). The error is
totally reasonable to a user who actively wants to use dynamic
plotting with loon but does not have loon installed. In that sense
your second cat (nice!) could be expanded to:

cat("Sorry 'bout that, chief, but if you really want to use 'loon',
then just install it from github first and your wish will be my
command! Alternatively, just use one of the other supported methods
like the one based on 'graphics' (the default).\n")

:-)

[Thanks to everyone for helping so far. It's good to know that this
does not seem to be a trivial problem which probably means that the
'dumbness-level' of this question was not too high...]. By now, I also
send an email to Uwe directly and mentioned this thread here. I'll
immediately post an update if there is any (if not 'plan B' will get
more likely).

Cheers,
M



>
> cheers,
>
> Rolf Turner