[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