[R-pkg-devel] CRAN packages suggesting other packages but not using them conditionally

Ben Bolker bbo|ker @end|ng |rom gm@||@com
Sat Dec 12 22:41:47 CET 2020



On 12/12/20 4:08 PM, Spencer Graves wrote:
> 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'

      on_cran() is intended to be used via testthat::skip_on_cran() 
(which is exported, unlike on_cran()).
> 
> 
>        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".

   The assumption of testthat is that it's going to be deployed via 
devtools::check(), which automatically sets the environment variable 
NOT_CRAN equal to 'true'. For testing on your machine, you could use

Sys.setenv(NOT_CRAN="true"); testthat:::on_cran()

or you could put

export NOT_CRAN=true

in the shell/in your testing pipeline.


> 
> 
>>    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".

  I agree that this would be nice.

   A simple mechanism would be to set an official/sanctioned/stable 
environment variable such as _R_ON_CRAN in all CRAN testing pipelines.

> 
> 
>        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
> 
> ______________________________________________
> 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