[R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally
Spencer Graves
@pencer@gr@ve@ @end|ng |rom e||ect|vede|en@e@org
Sat Dec 12 22:08:04 CET 2020
Hi, Ben et al.:
On 2020-12-12 13:43, Ben Bolker wrote:
> Apologies if I'm telling you something you already know:
>
> By default, fda::CRAN() uses the presence of environment variables
> matched by the regexp "^_R_" as a heuristic to decide whether it's being
> running on CRAN.
>
> testthat::skip_on_cran() calls testthat::on_cran() to look for an
> environment variable called NOT_CRAN equal to "true". The
> devtools::check() machinery automatically sets this variable.
> testthat::on_cran
Error: 'on_cran' is not an exported object from 'namespace:testthat'
Besides, on my Mac, I get:
> testthat:::on_cran()
[1] TRUE
My Mac is NOT CRAN, and I don't want that function to return TRUE on
my computer unless I explicitly run "R CMD check --on-cran".
> So: fda::CRAN() depends on breakable assumptions, defaults to FALSE
> in an empty environment. skip_on_cran() defaults to TRUE in an empty
> environment (but defaults to FALSE in a devtools::check() environment).
If future changes break fda::CRAN, I will have to deal with it then.
I'd be happier if the CRAN maintainers would develop a procedure to
make it easier for package maintainers do two things:
* Include tests in their package that run longer than the time
limit permitted on CRAN.
* Give error messages that the package maintainer wants to see but
that should be suppressed on CRAN or when the user decides to run "R CMD
check --as-cran".
In any event, I hope that I'll be able to continue using fda::CRAN as
I have been. If not, I will be forced to reduce the coverage of test
suites everywhere I use fda::CRAN. That in turn will make the code
harder to maintain and more easily broken in ways that I can no longer
easily test.
Spencer
> On 12/12/20 2:19 PM, Spencer Graves wrote:
>> I have tests in my code to detect when something like that is
>> not available.
>>
>>
>> I also have code in "\examples" to skip tests that would
>> encounter that.
>>
>>
>> Hadley's "testthhat:skip_on_cran" is supposed to suppress tests
>> like that on CRAN. I have so far failed to understand how to use this
>> function that Hadley wrote. Instead, I use things like the following:
>>
>>
>> if(!fda::CRAN()){
>> # Code that I want to run everyplace that's NOT CRAN
>>
>>
>> }
>>
>>
>> When I wrote "fda::CRAN", I was told that I shouldn't do it,
>> but I didn't see a better option, and I've been using it for several
>> years now without being given a reason to discontinue using it or
>> (better?) being given an alternative that seems better to me.
>>
>>
>> Spencer
>>
>>
>> On 2020-12-12 12:40, Michael L Friendly wrote:
>>> Thanks, Dirk
>>>
>>> Just to clarify--
>>> In my packages, candisc, heplots, vcdExtra I have mostly 2D graphic
>>> methods, but some 3D methods that use
>>> rgl. I therefore put rgl into Suggests:
>>>
>>> Could I solve this by making rgl a Depends: ?
>>>
>>> -Michael
>>>
>>>
>>> -----Original Message-----
>>> From: Dirk Eddelbuettel <edd using debian.org>
>>> Sent: Saturday, December 12, 2020 12:46 PM
>>> To: Michael L Friendly <friendly using yorku.ca>
>>> Cc: r-package-devel using R-project.org; Prof Brian Ripley
>>> <ripley using stats.ox.ac.uk>
>>> Subject: Re: [R-pkg-devel] CRAN packages suggesting other packages
>>> but not using them conditionally
>>>
>>>
>>> On 12 December 2020 at 16:24, Michael L Friendly wrote:
>>> | I got the email below concerning 3 of my packages but wonder if they
>>> | are false alarms or if not, how to locate & fix the problem.
>>> |
>>> | This concerns packages: ...
>>> |
>>> | Suggested packages should be used conditionally: see 1.1.3.1
>>> of 'Writing R Extensions'. Some of these are hard to install on a
>>> platform without X11 such as M1 Macs: see the logs at
>>> https://www.stats.ox.ac.uk/pub/bdr/M1mac/.
>>> |
>>> | You can check all of the suggested packages by setting
>>> environment variable _R_CHECK_DEPENDS_ONLY_=true -- see
>>> https://cran.r-project.org/doc/manuals/r-devel/R-ints.html#Tools .
>>> |
>>> | Is this a false alarm?
>>> |
>>> | In each case, the outfile contains:
>>> |
>>> | * checking package namespace information ... OK
>>> | * checking package dependencies ... NOTE
>>> | Package suggested but not available for checking: 'rgl'
>>> |
>>> | indicating that rgl is not avaiable on the testing machine. Then,
>>> | when checking examples an error is triggered when an example calls
>>> something that requires rgl.
>>> |
>>> | >
>>> | > heplot3d(Adopted.mod, hypotheses=list("Reg"=c("AMED", "BMIQ")),
>>> | + col = c("red", "blue", "black", "gray"), wire=FALSE)
>>> | Loading required namespace: rgl
>>> | Failed with error: 'there is no package called 'rgl''
>>> | Error in heplot3d.mlm(Adopted.mod, hypotheses = list(Reg =
>>> c("AMED", "BMIQ")), :
>>> | rgl package is required.
>>> | Calls: heplot3d -> heplot3d.mlm
>>> | Execution halted
>>> |
>>> | Yet, heplot3d seems to contain the required way to refer to the
>>> suggested rgl package:
>>> |
>>> | if (!requireNamespace("rgl")) stop("rgl package is
>>> | required.")
>>> |
>>> | So, I'm mystified. Can anyone help?
>>>
>>> This is not conditional use in the sense of my reading of WRE.
>>>
>>> What you have here is essentially an "assert()" and equivalent to
>>> stopifnot(requireNamespace("rgl"))
>>> which, in turn, is equivalent to a strong Depends or Imports as your
>>> package will experience a _critical error_ triggered by `stop()` if
>>> rgl is missing.
>>>
>>> The idea of a conditional use is to, well, be conditional. Below I
>>> make use of Rcpp if is present, but it is only a suggests:
>>>
>>> ## see the source files in the snippets/ directory of the package
>>> ## check for (optional, only in Suggests:) Rcpp, and also wrapped
>>> in a
>>> ## dontrun as it takes 10s at CRAN (yet only 3.5 here) yielding a
>>> NOTE
>>> if (requireNamespace("Rcpp", quietly=TRUE)) {
>>> Rcpp::sourceCpp(system.file("snippets", "convolveExample.cpp",
>>> package="tidyCpp"))
>>> }
>>>
>>> If the _suggested_ package is present, it is used. If not we quietly
>>> move on.
>>> (It's not the full story as the compilation occassionally takes
>>> longer, Windows complained so all this is now in a \dontrun{} block
>>> too. But the idea is generic and there are many more examples to be
>>> found.)
>>>
>>> Hope this helps, Dirk
>>>
>>> --
>>> https://dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org
>>> ______________________________________________
>>> R-package-devel using r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>
>> ______________________________________________
>> R-package-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
More information about the R-package-devel
mailing list