On Sun, Feb 25, 2018 at 11:16 AM, Rolf Turner <r.tur...@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 ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel